mojombo/semver.org — Issue #46: Extending SemVer for private nightly/continuous builds
Author: Haacked
Created: 2011-10-26 05:15:49+00:00
State: open

In looking at SemVer, it seems to only be concerned with how you version public APIs, which is great. But one thing we're struggling with is how to best manage internal-only nightly/continuous builds.

We want to set up an internal package manager server (NuGet) to share libraries with other teams in our org who are not in our source repo. The problem becomes, when we're starting to work on 1.0.1beta, we need a way to version each build of it (multiple builds could happen in a day). We want to reserve __1.0.1beta__ for the actual public release of that beta.

If you're interested in the full details, I [wrote it up in my blog](http://haacked.com/archive/2011/10/25/semver-nuget-nightly-builds.aspx).

One thought we had would be to have an optional extension to SemVer that made use of a fourth version part. This part would represent the build number for the release and is intended only for internal consumption. Sharing among teams. From a public API perspective, the build number should not be relied upon.

Internally, when sharing with other teams, we'll have the benefit of having all of our packages with the same public version, 1.0.1beta, but the build number can be used to determine last known good builds.

The sorting would be something like this (note, I'd probably use a number that represents the date in a real situation rather than 00X):

* 1.0.1alpha
* 1.0.1beta.001
* 1.0.1beta.002
* 1.0.1beta.003
* 1.0.1beta

One reason we like this approach is that the public part of the version never changes for a release from build to build. So all of our tools and other collateral doesn't need to change once we stamp a build as final and simply remove the build number.

Would love to hear any thoughts on this proposal.