50

I was explaining a proposed build system (Gradle/Artifactory/Jenkins/Chef) to one of our senior architects, and he made a comment to me that I sort of disagree with, but am not experienced enough to really weigh-in on.

This project builds a Java library (JAR) as an artifact to be reused by other teams. For versioning, I'd like to use the semantic approach of:

<major>.<minor>.<patch>

Where patch indicates bug/emergency fixes, minor indicates backwards-compatible releases, and major indicates either massive refactorings of the API and/or backwards-incompatible changes.

As far as delivery goes here is what I want: a developer commits some code; this triggers a build to a QA/TEST environment. Some tests are ran (some automated, some manual). If all tests pass, then a production build publishes the JAR to our in-house repo. By this point the JAR should be versioned properly, and my thinking was to use the build.number that is automatically generated and provided by our CI tool to act as the patch number.

Thus, the versioning would actually be:

<major>.<minor>.<build.number>

Again, where build.number is provided by the CI tool.

The architect dismissed this, saying that using the CI build number was an "abuse" of semantic versioning.

My question is: is this correct, and if so, why? And if not, why not?

herpylderp
  • 2,017
  • 3
  • 21
  • 27

2 Answers2

59

Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

So, version numbers (major, minor, patch) must be provided manually, as these are used to tell your users about changes in one place without them having to look at your changelog or some other document.

If you want to include your build number, then you may append them after a + (section 10):

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Residuum
  • 3,282
  • 28
  • 31
  • Quick followup @Residuum (and BTW +1 for the answer): should version numbers *always* be manually derived then? If not, what tools could be used in lieu of CI/build number? – herpylderp Aug 14 '14 at 14:22
  • 2
    @herpylderp not at all, Tom Preston-Werner's 'spec' is just his opinion, loads of other companies have different (generally very similar to each other) standards. In most of those, an automatically-generated number is part of the version. Use the CI build number is a sensible thing to do. – gbjbaanb Aug 14 '14 at 15:31
  • You can still use the CI tool, if the tool allows you to do arithmetic on build numbers. Whatever build you release as a major or minor version upgrade, plug in that build number to an expression for the version string which subtracts from the current CI build number. Voila, you've just reset your build number to zero for the new version, without actually resetting your build number. – KeithS Aug 14 '14 at 15:33
  • 2
    As for me, I just use [major].[minor].[revision].[SVN-Version] for DLLs, and [major].[minor].[SVN-Version] for installers. The CI build number is for internal use only, to show where a build that failed might have been re-run against the exact same codebase after a change to the CI environment (installing a key certificate, adding common libraries to the GAC etc). – KeithS Aug 14 '14 at 15:38
  • 1
    @gbjbaanb et al.: In every discussion about "semantic versioning" that I was part of, the definition from http://semver.org was the subject. Search the web for "semantic versioning", and at least the first page comes up with pros/cons about the definition from http://semver.org/. You are free to use your own versioning schemes, but do not call it semantic versioning, as this term is clearly defined. – Residuum Aug 18 '14 at 09:49
  • Manually versus automatic becomes a function of the build/deployment tools. I very much like your explanation of the distinction between patch and build from a semantic perpestive. +1 – Joel Etherton Apr 11 '23 at 18:10
6

One reason is that the patch may require several builds, so if you have version 5.7, and you want to patch it to 5.7.1, but your first 2 bugfixes fail to build when they are submitted to the CI system, then you will be at 5.7.3 before you've released your first patch!

The answer is to simply use 4 digits (as Microsoft systems tend to have). The 4th is a build number and is used "for information only". Generally people put the repository version number in there (if they use SVN or TFS or similar) which is really nice as you can verify which exact commit was used to build the binaries. If you don't have such a thing, then the CI build number is a reasonable approximation (as you'd hope your CI system can remember the build numbers and tie it to the repo history, but you're not reliant on the CI system remembering them - you can never delete old builds).

One thing to note, The Microsoft schema for versioning uses the 3rd position for build numbers. Chrome uses just 1 number. Ubuntu uses the date. There is no "standard" to use, except that all numbers must increment.

Community
  • 1
gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 7
    Although there's no standard that's universally used or enforced, the question appears to be specifically about [semantic versioning](http://semver.org/) which does have a specification. – Doval Aug 14 '14 at 15:44
  • Even that is broken in the field, for example Microsoft's [NuGet versioning](http://docs.nuget.org/docs/reference/versioning) uses semver, in a broken way (using the prerelease style for build numbers), and Ruby uses [major.minor.teeny.patch](https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/). Anyway, as the build number can be part of the semver, the architect was talking tosh (though admittedly, it should be +build, not in the 3rd position). – gbjbaanb Aug 14 '14 at 15:54
  • 2
    The SemVer 2.0 spec is from 2013 and the 1.0 spec is from 2012 as far as I can tell. It's likely NuGet and Ruby were doing their own thing before the spec appeared. It's not like the SemVer spec is novel; it just formalizes what people have already been doing so we can all finally agree on one way to do it instead of a dozen variations. – Doval Aug 14 '14 at 15:58
  • " you have version 5.7, and you want to patch it to 5.7.1, but your first 2 bugfixes fail to build when they are submitted to the CI system, then you will be at 5.7.3 before you've released your first patch!" ok, but so what? I don't recall anything in semver saying the numbers must not skip. – Andy May 16 '15 at 22:46