Take the 2-minute tour ×

Our current method of creating a product release is to tag all of our component repositories with the next appropriate version and then modify a master build script with these new version numbers for each component. The master build script will then be run and it will perform a SCM checkout of each component, then modify the AssemblyInfo.cs file so that the compiled .exe (or .dll) has the correct version number, and then compile the component. All of these components are then coalesced into a product release which is "versioned" with a pure marketing decided number.

So our process falls under the "tags drive the build" description, but I am not certain that is the best method. Specifically, where I see this failing us is if we were to integrate our release build into the CI process, it seems like it would be backwards.

Not just that, but where in a typical release-management process does the decision for the new component version numbers come in? Someone has to decide when component A goes from 2.1.4 to 3.0.0 and if library B should change from 6.3.2 to 6.3.3 or 6.4.0. Where are these version numbers stored and at what stage are they decided? Currently, we make these decisions at the "last moment" and they are stored in the master build script. The master build script itself is versioned and is tagged with the "marketing" version number.

share|improve this question
please don't add such meaningless edits. Add signal, not noise: faq –  Jeff Atwood Aug 8 '11 at 15:10

5 Answers 5

There are different right answers, depending on your product release cycle, patch approach, etc.

In the areas I'm working with right now, we tag RC builds with an incrementing integer. CI-style builds don't get versioned. I'm not sure what happens on the marketing side. :-)

share|improve this answer

Semantic Versioning can help you with identifying when to bump the version and what to bump it to.

A few key points:

  • Backward-incompatible changes get a major-version bump (3.2.9 -> 4.0.0).
  • Backward-compatible feature additions/changes get a minor-version bump (3.2.9 -> 3.3.0).
  • Backward-compatible non-API-altering bug-fixes get a patch-level version bump (3.2.9 -> 3.2.10).
share|improve this answer
This is a good system. Often the decision is arbitrary, but I think in general this is right. Backward incompatible or anything that can be seriously classes as a "major change" to how the app works. –  Robert Mark Bram Oct 13 '11 at 12:00
Not only should backward-incompatible be classed as "major change", such changes should be forced by versioning policy to be batched together into a painful single major upgrade rather than strung through a long and painful sequence of minor upgrades. Semantic versioning does this. –  yfeldblum Oct 13 '11 at 13:10

The system I use has a version number file containing the major and minor version numbers, my CI server uses a checked in change to this file to trigger a "release" build. The CI server adds on a build number to create a major.minor.build version and then tags the code used for that build.

share|improve this answer
Hmmmm....I'm liking this idea. I will have to think on this one a bit. –  Dave Nay Oct 13 '11 at 20:01

The way we usually work is we branch with a meaningful name so we know what it is, and tag with an incremental version number as the final release. A smaller increment for a small change (1.2 -> 1.3) and a larger increment (1.0 -> 2.0) for larger features.

share|improve this answer

I think "tags drive the build" is a good system in general, because it is easy to understand and use in all stages of your dev/test/qa/release cycle. If you are feeding a tag into your build script, you are deliberately saying "build x.y" is ready for the next step.

A build number that comes out of a CI process is useful too, but might not capture change information with the same grace - which is more descriptive: 2.3.5 or 23432?

No matter what public system of labeling you use, make sure detailed versioning information is accessible for debugging/reporting purposes - be as accurate as possible: version number, CI build number, source control revision number, build date and time - whatever data you need to nail down exactly what build you are dealing with.

As for the decision points, yes ultimately they are arbitrary and come down to whatever works. The semantic versioning system @Justice mentions is great: the important thing is that the team should be able come up with a system that is fairly easy to use when deciding what version number to use next.

share|improve this answer

Your Answer


