what's your strategy to increase build number?
+4
A:
Most software has a hierarchy of version numbers:
- The "marketing" version number (like "Windows 7")
- The major version number - usually incremented when there's a major new version that breaks some compatibility with a previous version, adds a major new capability, requires purchasing an upgrade, or more.
- The minor version number - upgraded every time there's a bug-fix or minor feature enhancement that's released to the public
- The build number - this should be incremented every time any change is made to the program, so that if someone finds a problem in a nightly build or beta-test version, you can identify exactly which version was being tested. This number is often a revision number directly from your version control system like Subversion, or a timestamp, or something similar that makes it easy for you to roll back the code to that version if necessary.
dmazzoni
2009-12-07 07:43:47
+1
A:
- All the dlls must have the same version number for one release.
- Build number consists of "
MajorVersion.MinorVersion.BuildNumber.Revision", usually I keep theRevision Numberto be 0. Only the first 3 numbers are changed. - For every nightly build,
BuildNumberwill be incremented automatically. I will manually increasemajorversionandminorversionif the changes are sufficiently big.
Ngu Soon Hui
2009-12-07 07:44:20
A:
Every checkin should be tagged a version, use the subversion current version as the part of the build exe version.
Priyank Bolia
2009-12-07 07:44:32
even for refactor checkin?
Benny
2009-12-07 07:46:29
@Benny: Yes, absolutely. You never know when your refactoring might unintentionally break something.
musicfreak
2009-12-07 07:53:40
@Benny: Yes, as musicfreak said, every check should generate a build, and the build version is derived from the checkin counter.
Priyank Bolia
2009-12-07 10:12:44
A:
It's quite reasonable to increase the build number for just every build. This way testers can tell more exactly which build they find a bug in and when it is verified to be fixed.
sharptooth
2009-12-07 07:45:03
And definitely don't get into the situation where you've got two different sets of binaries that claim to be the same version number. If you're looking at file modification times to track down a particular build, you're doing it wrong...
Tim Robinson
2009-12-07 07:47:02
A:
We have a build number that's incremented on every build (formal or otherwise). We use a CruiseControl.NET labeller for this.
We have a version number that's incremented by hand only on formal releases, and we define that centrally in one of the CC.NET scripts, which are held in source control.
Tim Robinson
2009-12-07 07:45:39
A:
Like everyone says, increment the build number for every build. We set the major/minor numbers by hand when we do a branch, a branch is usually done a few weeks before release, then that branch gets regression tested. Builds done on the branch still get incremented though.
slugster
2009-12-07 07:50:54