Versioning for deployments

[tohuwabohu-io]

Is your feature request related to a problem? Please describe. I had some troubles with cached images on fly. Deployments should put a version label on produced artefacts to prevent that.

Describe the solution you'd like Calendar Versioning: The easiest solution would involve the current date as version string during the 'Deploy' github action workflow.

1. Add an additional step after the setups were completed to define the version like echo "{name}={value}" >>"$GITHUB_OUTPUT"
2. Make that value available as a flag during the gradle build process
3. Put that value as label on the docker image
4. Put that value as label on the fly image

Format: "yyyy.MM.dd"

Upsides:

• Quick and easy identification for the time the last build and deployment happened
• No additional environment variables necessary
• The version string would always have the same length
• No need to increment and (git) commit a value during the build process

Downsides:

• No indication of major version jumps
• No room for customization
• Not a common version number format
• Strict restriction to one version per calendar day

Describe alternatives you've considered Semantic versioning: https://semver.org - As much as I like that approach in general, this project is a kind of closed ecosystem on its own that does not expose an external API. Users won't care about major changes as they can't use an older version instead.

Additional context The version number should also relate to flyway database migration versions. The version number should be displayed in the UI and logged during service startup.

[tohuwabohu-io]

The cd workflow now follows the calver principle and uses an existing github action that also creates a release. The version is injected into .env at build time to display it in the UI. The version is passed as parameter to gradle at build time and will show up on application start.

The existing flyway migration was renamed. Let's see how that plays out after the first deployment.