Correct support of SemVer 2.0

i’m currently using Teamcity + Octopus + Octopack to build and deploy.

What I want is to generate a version number in the following format


Unfortunately octo.exe doesn’t seem to accept that format. But it accepts 1.0.0-develop86. I see the following in the buildlog of teamcity

13:03:34]Release plan for release: 1.0.0-develop86
[13:03:34] # Name Version Source
[13:03:34] — ------------------- --------------- ------------------------------------
[13:03:34] 1 Demo.Todo website User specified
[13:03:34]Creating release…
[13:03:34]Release 1.0.0-develop86 created successfully!
[13:03:34]##teamcity[setParameter name=‘octo.releaseNumber’ value=‘1.0.0-develop86’]
[13:03:35]Deploying Demo.Todo 1.0.0-develop86 to: Test (Guided Failure: Not Enabled)
[13:03:35]Waiting for 1 deployment(s) to complete…
[13:03:55]Deploy Demo.Todo release 1.0.0-develop86 to Test: Success

Another issue is that I haven’t been able to use 1.0.0-develop.86 as a version for the nuget package that’s being generated during build.

The nuget package is published to the built Teamcity repository.

Hi Saber,

Thanks for getting in touch! This is a limitation of NuGet - in the attached screenshot you’ll also see that NuGet Package Explorer doesn’t support this format. I know this isn’t the answer you’re looking for but unfortunately there isn’t too much we can do about it until NuGet also supports this syntax.


Ah I see… No worries. Then I suppose I have to live with the missing last dot :wink:

Thanks for posting the question and clarifying from Octopus. This is a pretty critical feature that is missing. We’ll be able to work around of course.

A bit off topic, but any recommendations on how to create such a pre-release package in Team City using a automatic build incrementer?

There’s a known issue using 1.0.0-develop{increasing number} as NuGet orders it alphabetically. So pretty much there are two solutions

  1. Padding and using build number of TC: 1.0.0-develop0000086 (numbers zero-padded to 6 in length in this example)

  2. Using timestamps: 1.0.0-develop-20141105120000

Both are hard to do in TC wihtout any plugins I find.

Hi John

We’ve just accepted a pull request for OctoPack which may solve your problems, take a look at this

Would that help you ?



No, that would change the package id of the nuget package, which is very much not recommended.

Hi John,

We do this using a PowerShell step as the first step in our TeamCity build process. We leave the build number TeamCity generates, then based on the branch, we append a tag. See below for an example:

# These are project build parameters in TeamCity
$prodPrefix = "%MajorMinorVersion%"
$prePrefix = "%MajorMinorVersionPreRelease%"
$devPrefix = "%MajorMinorVersionDevelopment%"
$release = "%build.counter%"  # TC's auto-incrementing number

$branch = ""
$branch = $branch.substring($branch.lastIndexOf("/")).trim("/")

write-host "branch: $branch"

if ($branch -eq "master") 
 write-host "This is a master build"
 $release = ($prodPrefix + "." + $release)
elseif ($branch -match "release-.*") 
 write-host "Special release build"
 $release = ($branch -replace 'release-(.*)','$1') + "." + $release
elseif ($branch -eq "release")
 write-host "This is a pre-release build"
 $release = ($prePrefix + "." + $release)
elseif ($branch -eq "develop")
 write-host "This is a vNext build"
 $release = ($devPrefix + "." + $release)
 write-host "This is a feature branch build"
 $release = ($devPrefix + "." + $release + "-" + $branch.Replace("-", "").Replace("feature", ""))

write-host "##teamcity[buildNumber '$release']"


Thanks Paul.

From what I can tell this script bypasses the issue by inserting the counter at the patch. I presume that you then at release build will have to match the MAJOR.MINOR.PATCH to be the same as the pre-release-version, so you re-set the counter in TC manually.

Work on a pre-release will generate the following packages

“Okay, we are finished with the 1.1-version, and the final package version will be 1.1.3. Update TC-variable %MajorMinorVersionPreRelease% and the TC counter so that it says 1.1.3”

Either that, or you don’t care about the matching of MAJOR.MINOR.PATCH when working on pre-release-package and decide upon what kind of release version this is at the time of generating a release-package.

I’m guessing it’s the latter?

What I would like is another setup

Feature branch for 1.1.3
packageid.1.1.3-branchname-{ zero padded counter/timestamp}
packageid.1.1.3-branchname-{ zero padded counter/timestamp}
packageid.1.1.3-branchname-{ zero padded counter/timestamp}

Release build
"Set Major.Minor.Patch to 1.1.3 and package away)

Hi John,

Sorry if my script was misleading, I was just pasting something we had to be a starting point for you, it wasn’t intended to be exactly what you needed. Here’s a new version that might be closer to what you need:

# These are project build parameters in TeamCity
$majorMinorVersion = "%MajorMinorVersion%"
$release = "%build.counter%"  # TC's auto-incrementing number

$branch = ""
$branch = $branch.substring($branch.lastIndexOf("/")).trim("/")

write-host "branch: $branch"

$release = $release.PadLeft(6, "0")

if ($branch -match "release-.*") 
 write-host "Special release build"
 $release = ($branch -replace 'release-(.*)','$1') + "-release-" + $release
 $release = ($majorMinorVersion + "-" + $branch + "-" + $release)

write-host "##teamcity[buildNumber '$release']"


Assuming MajorMinorVersion is set to 1.1.3 and the TC auto incrementing counter is 15.

  • Branch: foo, version: 1.1.3-foo-000015
  • Branch: bar, version: 1.1.3-bar-000015
  • Branch: release, version: 1.1.3-release-000015
  • Branch: release-1.1.4, version: 1.1.4-release-000015 (special case)

Hopefully this is a good starting point for you to adjust to suit your needs!


A wrote a blog post about this with more details:


Hi guys,
Is this now fixed in Octopus Deploy 3 (and the newly released Nuget 3?) or not?


Hi Kieran,

It seems like they may have been fixed in NuGet 3.0, but Octopus is still using NuGet 2.8.3 since NuGet 3.0 was pretty recent. We’ll be testing against NuGet 3.0 and upgrading soon, and we’ll check if we can support the full SemVer 2.0.


Thanks Paul - especially for the rapid response. Thats excellent news. The
story with GitVersion, TeamCity and Octopus Deploy is so close to being
fantastic now - with SemVer2 (assuming Nuget is supporting it fully) it
will be almost seamless.

Any news on this? it’s been a few months.

Hi Martin,

Unfortunately no update on this at the moment.

We’ve been working on the channels feature for 3.2. We’ll probably aim to include support for SemVer2 with a 3.2.x release, however not immediately.

Sorry it’s not better news!

I’m still struggling with this having to add a bunch of PowerShell scripts in our builds to accommodate limitations of Octo.exe.

I know the nuget command line still doesn’t support SemVer 2.0. Does octo.exe use the nuget command line under the covers? Do we have to wait until the nuget command line is updated before octo.exe can be fixed?

Our current solution is to override the teamcity version in the Create release step using a custom powershell script.

Hi Brett,

Thanks for getting in touch. To answer your specific questions, yes, octo.exe uses the PackageBuilder from NuGet.Core to build packages, so we are constrained to NuGet 2.9 at the time of writing.

Rest assured we are feeling the same pain for our own builds, and it would be really nice if the pipeline from end-to-end supported SemVer 2.0 out of the box. We are determined to make this experience better for everyone but we need to move carefully to maintain compatibility with a lot of moving pieces.

Have a look over this GitHub Issue which should shed some light on what we’re planning to support for packaging moving forward. I’d be interested in your thoughts after you take a look.

Hope that helps!

How about now in 3.3 w zip/tar support?

Hi John,

Thanks for getting back in touch. By going through and introducing alternate package options, we’ve started the process of decoupling ourselves from NuGet, with the next step to move our use of NuGet.Core.SemanticVersion (which is SemVer 1.0) to something that supports SemVer 2.0.

We want to complete this work in stages since it impacts so much of the codebase. Our next priority is to ship multi-tenant deployment support. Whilst there may be room to fit SemVer 2.0 support into Octopus 3.4 as a side-project, we can’t make any promises to that end.

In the meantime we will all have to wrestle SemVer 1.0 (and the NuGet 20 character limit for SpecialVersion) to do our bidding.

Sorry if that’s not the news you wanted to hear, but I hope it helps.