Doing a pseudo-CD strategy for dev environments and we want to make sure all interim builds are tagged and versioned in a way that provides traceability but also conforms to semver so that helm etc doesn't yell at us and also I can sleep at night knowing I've bikeshedded correctly. I was thinking about the semantics of semver and how intra-release builds/versions might be tagged.
Assuming our process doesn't provide sufficient reliability for a "look-ahead" version (e.g. I don't know if our next release is going to be a major, minor, or patch increment), what would the best practice be for applying versions to builds between releases.
e.g.
Given last release of 1.2.3
Given a timestamp postfix for build metadata (e.g. a build might be called {version}-1668519441 )
Given that I don't know if the next official release is going to be 2.0.0, 1.3.0, or 1.2.4
Do I:
- Apply the build number to the previous versionto generate the build version? 1.2.3-1668519441
- this feels kinda yucky because technically it's the build of the next alpha version, not a build of the previous release version
- Apply the build number to my best guess next version to generate the build version? 1.3.0-alpha-1668519441
- this feels better, but we get burned if we guess wrong
- simply weep, because the answer is "there's no one right answer" and now I have to make my own decisions?
- ;-;