Versioning with an automatic build system

We recently moved to an automatic build system (something internal, not Hudson or Teamcity, yet).

Our version is stored in a header file and is included by some cpp and resource files. It is also used by the installer.

Its format is A.B.C.D where:

• A didn't change in years.
• B changes rarely (major version).
• C changes with minor versions.
• D changes when a new minor version (bug fix) is delivered to QA.

Up until now, the one incharge of building a new version, incremented 开发者_运维知识库C/D by hand (D being the more common) before starting the build, checked in the change and then started the build. The version stayed the same until that person built the app successfully.

Naturally with the move to an automatic build system I'd like to get rid of the manual step of changing the version number.

How should this be approached?

• Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?
• Is the increment step a task in the automatic build system?
• After incrementing, should I commit the version file?
• How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
• What do I do if the build failed? Still increment the version and commit?

Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?

The Eclipse Foundation adds an E element, the date and time of the build. I think that's a good idea for the internal-test builds. It's up to you if you want to use E for the QA builds.

Is the increment step a task in the automatic build system?

Seems logical, but you have to have some way of telling that task what kind of build you're doing.

How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.

Commit the version control file with the source code.

Basically, your development build process should proceed in the following order.

• Build the product from the development source code.
• If the build succeeds, increment the version number.
• Commit the source code and the version control file.
• Build the product again from your version control system.
• If the build fails, back out the source code and version control file commit.

This tests your build and your build process. The second build should never fail, but if it does, there's a problem in the process.

Your production build process would start at the 2nd step, skipping the 3rd step.

What do I do if the build failed? Still increment the version and commit?

My E is auto-incrementing. :-) I'd say no for the other elements A, B, C, or D.

Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?

Yes, change your process so that D increments with every build (successful or not) rather than with every delivery to QA.

It can be quite frustrating having several builds, some working some not and not being able to tell them apart because the failed build is the same id as the good one, well eventually. Then you don't even have to consider if it was on the same day or in the same hour.

Is the increment step a task in the automatic build system?

I'd have the build system auto increment the build number (D) only.

After incrementing, should I commit the version file? How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.

The version control storage is all about recording the detailed noise.

I'd have the version update checked in, this can make a reasonable tag visible in SVN of what build the previous changes where included in, have the build system ignore checkins by the build system, or those identified as the version update checkin.

Then to view the version history you should have an appropriate tool that allows you to filter the history to show you the view you need, in some cases excluding the version commit tags.

If you choose not to commit the version number for each build, then it might be a good idea to maintain the version number in a separate file to avoid accidental updates.

What do I do if the build failed? Still increment the version and commit?

Still increment the version number, I wouldn't commit the version number unless it was a successful build. You can have a variety of failures outside of source change in version control that don't need to be recorded - build server out of disk, server crash, compiler got all wobbly in the knees building 32 and 64 bit, debug and release aix, linux and windows builds at the same time...

You could consider to use the convention for .NET assemblies, as described in the documentation for class System.Version. Quote:

• Build [your C]: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
• Revision [your D]: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

How are you going to automate this? I mean, what system would know that "this build is the release build!". It would seem to me that all your digits in a version is relevant. If the next release (D + 1) requires two builds, then would A.B.C.D+2 be the next version? Sounds fishy to me. I would rather add the build number on top of the version instead, if it's really necessary to have this information on your DLLs and EXEs.

I don't think the build number is a relevant piece of information to have attached to the binary, unless you distribute files of version A.B.C.D from different builds (which you shouldn't do anyway!)

I would setup the build server to store the artifacts (DLLs, EXEs, MSIs, PDBs, etc) in a directory, whose name includes the build number and version, and then burn DVD/whatever from there. If you ever need to back track from a version to a specific build, you can use this information, provided that you keep an archive of your releases (recommended!).

I would recommend the use of autorevision.

You could still keep the A.B.C.D format for your tags and use the script to create header files that are generated at build time that have the needed info in them.