Agile – artefact versioning – product versioning vs semantic versioning

agilescrumsemantic-versioningversioning

The following situation:

  • a product which consists of multiple components, each component
    versioned individually (all artefacts of the same component having the same version)
  • POs are talking of product version X and plan releases X.a, X.b containing specific functionality
  • each sprint a new release is made (that potentially is installed on a demo environment)
  • sprint releases increase the patch version e.g. 1.0.0, 1.0.1
  • the minor version would be increased once we start development on next release planned by POs e.g. X.a = 1.0 and X.b = 1.1

We started the discussion about introducing semantic versioning (http://semver.org/) for the components but there are some doubts.

  • Some find it makes it more complicated if the dev has to decide if the minor or patch version must be increased and raised the point that some bug fixes are introducing new functionality (don't ask)
  • Some are rejecting the idea of increasing the minor version as the release planned by POs may not be achieved yet i.e. it's not yet feature complete
  • With current versioning engineering can easily see which environment potentially needs to be updated depending on whether the version is 1.0.x or 1.1.x
  • Releasing according to semantic versioning after each sprint we would reach high major and minor versions which some dislike also because some curious customers check the versions

What practices do other companies apply when it comes to versioning in a scrum environment? Do you release a version after each sprint? Where do you see the advantages of the approach you chose?

EDIT: Maybe it was not clear from my description but the component versions do not exactly align with the product versions, the only correlation between the two is the timing when major/minor will be increased e.g.:

  • product 1.0
    • component A 3.2
    • component B 4.5
  • product 1.1
    • component A 3.3
    • component B 4.6
  • product 2.0
    • component A 4.x
    • component B 5.x

I agree that the product version should have nothing to do with the technical version – it's a label. That's why I am trying to find out how others solved this and what the arguments were. 😉

Best Answer

A simple solution, not just for agile teams, is to separate the engineering version from the marketing version. One well-known instance of this is Microsoft's versioning for Windows NT:

  • the very first version was 3.1, not 1.0
  • marketing version Windows 2000, engineering version Windows NT 5.0 (MS had decided to stop development of the DOS-based versions, and consequently dropped the NT from the product name, despite the fact that at the same time, Windows ME was released)
  • marketing version Windows XP, engineering version Windows NT 5.1
  • marketing version Windows XP Professional x64, engineering version Windows NT 5.2 (Interestingly, the port to AMD64 got its own version number, whereas Windows XP 64-Bit Edition, the port to IA64, did not)
  • marketing version Windows Vista, engineering version Windows NT 6.0
  • marketing version Windows 7, engineering version Windows NT 6.1 (actually, the engineering version was 7.0 originally, but Microsoft found out during compatibility testing that a lot of software was testing for major == 6 to figure out whether to enable post-XP features, and rather than breaking all those apps, Microsoft decided to revert the major version to 6. During the keynote, they joked that Windows 8 would have version 6.1.1, and so on, for the same reason.)
  • marketing version Windows 8, engineering version Windows NT 6.2
  • marketing version Windows 8.1, engineering version Windows NT 6.3
  • marketing version Windows 10, engineering version Windows NT 10.0 (MS re-aligned marketing and engineering versions with Windows 10, however due to the new rolling release model, it is imaginable that the engineering version may change but the marketing version stays the same)

[Note that Microsoft also has release numbers as well as monotonically increasing build numbers, none of which show up in the marketing versions.]

So, you follow SemVer for your engineering versions (which, in an agile project will likely lead to high version numbers), and the marketing department is free to chose their versioning scheme however they want. You can think of a marketing version as a human-readable short label for a set of features that just so happens to be formatted like a version number.

Related Topic