Non-SemVer release versioning?

It looks like Octopus Deploy release versions have to be SemVer-compliant, but I’m not sure that’s an appropriate restriction for all cases.

Here’s the limitation I’m running into:

  1. If we’re deploying to QA, and we have multiple builds of the same major.minor.revision, then the build number needs to be included in the release version to give the QA folks an accurate picture of what’s actually deployed in the QA environment.
  2. If we’re tweaking our deploy scripts, process, and variables in Octopus, then we’re going to be releasing the same NuGet package multiple times.

Because SemVer is always major.minor.revision.build, there’s no way I can see to keep all of the required info: we either have to lose the build number or the release revision number. I think a more appropriate release numbering system (e.g. for a release whose number is based off a single NuGet package) would look like this:

package-major.package-minor.package-revision.package-build.release-revision

Of course, that’s not SemVer-compatible, but I think it’s a reasonable way to show all of the version info that’s needed in this use case.

Do other people in the community think this is a good idea? Are other people running into similar issues?

Hi!

Thanks for getting in touch. You raise a good point, versioning is a difficult problem to solve, and unfortunately, buried in the weight of many opinions and backwards compatibility. Because Octopus Deploy uses NuGet, we are beholden to their implementation of SemVer, which happens to support 4 x version numbers (instead of 3) and a SpecialVersion (like -beta0001) used to designate pre-releases (which can be at most 20 characters long).

There is momentum gathering around SemVer 2 and some tools like GitVersion, and NuGet is moving to support SemVer 2 in NuGet 3.

There has been some previous discussion of versioning with Octopus Deploy that I found insightful: http://help.octopusdeploy.com/discussions/problems/21030-correct-support-of-semver-20 and Paul’s blog post on how we’ve been doing versioning with TeamCity: http://octopusdeploy.com/blog/teamcity-version-numbers-based-on-branches

At the end of the day I tend towards the pragmatic and find a reasonable compromise that works based on the limitations enforced on me. I’d recommend taking a look through these and try a versioning scheme that works for your situation.

One recommendation would be to create a Release in Octopus called 3.1.19.2567-beta1 deploying your packages at 3.1.19.2567 so you can test out your deployment changes, get them right, and then create Release 3.1.19.2567 deploying packages at 3.1.19.2567.

Hope that helps!
Mike