Search code examples
versioningsemantic-versioning

Using semver, should pre-release versions be based off the previous version number, or the next version number?

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:

  1. 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
  2. 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
  3. simply weep, because the answer is "there's no one right answer" and now I have to make my own decisions?
    • ;-;
Solution

  • Reasonable smart will be "modified 1" (because "internal builds" are just builds, for which we have to have "some id", which must just allow internal identification of it and nothing more):

    with something like git describe HEAD you'll get 1.2.3--14-g2414721, 1.2.3-21-g975b, 1.2.3-25-g2dc6 etc and any of these builds later according to (existing, I hope) Release Policy may become 1.2.4, 1.3.x or even 2.x.x (see idea of conventional commits and versioning of releases based on it), "just because..."

    Answer 3 is daring and unequivocal version, but it's bad, because it does not answer the question and does not give at least a mediocre solution to the problem, but it's bad, because it does not answer the question and does not give at least a mediocre solution to the problem