CruiseControl.NET versioning

Added by Daniel Nauck over 6 years ago


after our SCM switch from Subversion to git the old version scheme on the build server is now insignificant.

Old version scheme

We was using the AssemblyVersionLabeller with the following version scheme:

<major>.<minor>.<ccnet build counter>.<subversion revision>

Since git does not have a numeric revision but sha-1 hashes we cannot use the old version scheme.

The new approach

The new version scheme cannot depend on SCM revisions and we want to distinguish nightly builds from release builds.

So a new version could be like this:

<major>.<minor>.<ccnet build counter>.0

  • Major - The major CCNet version, simply marketing. Will be increased on very major changes.
  • Minor - The minor CCNet version, will be increased on smaller code changes. A odd version is a development version, e.g. a nightly build, and a even version will be a release version.
  • Build - The build counter from our build server, should be resettet to 0 on every Major/Minor version change.
  • Revision - Currently not needed, is always 0.

We could also add the git short hash to the AssemblyDescription attribute for each build.

Stable release builds will be tagged by our build server, nightly builds not anymore.


  • - CCNet release build no. 1 in the stable 1.6 branch
  • - CCNet nightly build no. 32 for the upcoming 1.8 release

What do you think?

Replies (11)

RE: CruiseControl.NET versioning - Added by Michael Powell over 6 years ago

It's fine with me as long as we can still distinguish between stable releases.

Best regards,


RE: CruiseControl.NET versioning - Added by Philip Sayers over 6 years ago

Have you considered making use of the revision field?
A revision value of 0 (zero) means a stable release.
A revision value of 1 (one) means a nightly/unstable release.

This way you are not limited to only even numbered releases.
Major/Minor still represents the appropriate branch.
Build still represents the build number from the build server.

So with the 1.6 branch for example you get nightly builds looking like this:

Release builds look like.

RE: CruiseControl.NET versioning - Added by Leszek Ciesielski over 6 years ago

+1 for the original proposal - the even/odd convention is pretty well known among programmers. Also, embedding the git short hash as an assembly attribute is a must-have IMHO and should be done for the developer builds as well as the ones performed by a build server.

RE: CruiseControl.NET versioning - Added by Ruben Willems over 6 years ago

I do not really care about the versioning, as long as we know what release it is 1.6, 1.7 or whatever.
A clear distinguishment between a nightly and an official release is indeed a must.

As far as I remember, there is nothing foreseen that will automatically reset the build number back to 0 after a change in major /minor.

Do we really need to?
1.7.5678.0 is a nightly build of 1.7
1.8.6789.0 is a release build of 1.8
when we do a fix on 1.8 it will become 1.8.7689.0 for example.

what's the benefit of having the 1.9 start with again?
we did not do this is in the past, so why start now?

if we had a trigger that would do this, I do not really object, but having to do this manually every time, ...
that's something that will be forgotten one day.

my 2 cents

RE: CruiseControl.NET versioning - Added by Ruben Willems almost 6 years ago

look at

we could store the git commit id into AssemblyInformationalVersion

[assembly: AssemblyInformationalVersion("abcde1234567890")]

this results into ALINK : warning AL1053:
does not have the expected notation

it does show up in windows explorer ,
but we get a lot of these warnings

setting the git last change into an other property does not expose it in windows explorer
any idea on this

integration property to use for final solution : LastChangeNumber

RE: CruiseControl.NET versioning - Added by Ruben Willems almost 6 years ago

the original proposal is ok for me.

we only need to be able to update the numbers easily.
I just wonder : we're now working on 1.7, which will according to the original proposal, never be released.
it will 'magically' transform into 1.8

from that point on 1.8 is born, and we immediately start to work on 1.9

critical fixes can be done on the 1.8 branch.

meaning that the following changes are needed for a release :
  • creating a branch in git on the trunk, and name it 1.8 (in this case)
  • point the CCNet-Stable project to it (project name in ccnet.config)
  • update the CCNet-Nightly project with the new label prefix (1.9)

is this correct?

RE: CruiseControl.NET versioning - Added by Zev M almost 6 years ago

Just to throw in my 2 cents...
Our team does a continuous builds with an official signed build every week. We use Major.Minor.Release.ChangeSetNumber. On continuous builds it would be something like, but when we do a signed official version, it goes to, where we increment the 3rd number and set the 4th to 1. We set the last number to 1 so we can differentiate the official builds with the non-official. After that, The the next continuous builds would be , back to the ChangeSetNumber. We manually run the Signed Builds so we make sure that everyone is ready beforehand, but its still a simple force build with "OfficialBuild" as an argument instead of "ContinuousBuild", so it would be easy to set as an automatic trigger.

RE: CruiseControl.NET versioning - Added by Zev M almost 6 years ago

I still think its annoying for release versions to skip numbers. I look at the release notes when upgrading development software to know whats happening. In this case, it would probably take me a minute or so to figure out that 1.7 was a beta build.

Would it throw you off if Internet Explorer 9 instantly went to IE 11?

RE: CruiseControl.NET versioning - Added by Ruben Willems almost 6 years ago

you've got a point there, but switching main number has an advantage to

we now release,
suppose we encounter a critical bug (let's hope not)
we can easily update to
which makes it easier to find the latest release of a certain version

just assume we kept the 1.7 numbering
number 1.7.746.8065 will be the code for the release

and we encounter that critical bug
the next release would/could be 1.7.750.8065
makes it more difficult in my point of view

RE: CruiseControl.NET versioning - Added by Zev M almost 6 years ago

We don't run into critical issues too much. Typically is a specific client has an issue, and we just give him one of our weekly signed builds with the fix.

I didn't notice that the 4th number wasn't used. We use Major.Minor.Release.Changeset, which is the very close to y'all. We have a incremented release number between your 2nd and 3rd number. We use our 3rd number for weekly builds, and the larger official builds with the 2nd.

What's y'alls release process? We always run unit tests, but on releases we do some additional manual tests.

RE: CruiseControl.NET versioning - Added by Zev M almost 6 years ago

I talked to some co-workers about this and one of them told me that's how Linux does it and it's fairly common. (I looked into it and in 2004 version 2.6 was the last version to use that system)

Either way, it works =)