Octopus and Teamcity failure due to package version mismatch

[csecharith]

We use Semantic Versioning for our builds. From teamcity we get packag version numbers such as 1.0.0+73, 1.0.0+74 with incremented build numbers.

If package 1.0.0+73 is already installed and build 1.0.0+74 created afterwards, it doesn’t let to deploy 1.0.0+73 to any other environment. Issue is that teamcity is offering the latest build(1.0.0.+74) of the same version instead of correct old package(1.0.0+73).

So octopus deploy gives the following error.

Acquire packages
The step failed: Activity failed with error ‘The package version ‘1.0+74’ for ‘TestApp’ returned from the package repository doesn’t match the requested package version ‘1.0.0+73’. For a detailed troubleshooting guide go to Troubleshoot missing packages | Documentation and Support’.

What’s the recommended way to sort this issue? Thank you.

[Daniel_Fischer]

Hi @csecharith,

Thanks for getting in touch! To start, I’ll mention our documentation on package versioning. Octopus is built on SerVer 2.0 practices, which insists that metadata be ignored when determining package precedence. (Point 10 on the SemVer website.)

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

This means that Octopus wont differentiate any version difference between 1.0.0+73 and 1.0.0+74. For Octopus to consider one of these versions later than the other, you will need to change a value that isn’t build metadata.

Let me know if that helps or if you have any further questions.

Best regards,
Daniel

[csecharith]

Hi @Daniel_Fischer ,

Thanks for your reply. Yes, I know that’s the case. I am wondering if there is a workaround to make this work instead of increasing the patch number for each build?

@Daniel_Fischer

For Octopus to consider one of these versions later than the other, you will need to change a value that isn’t build metadata.

Is there any other value that we can change instead of patch number?

Can --packageversion argument to the Octo.exe help in this scenario?

Octopus does not use the package corresponding to the release version

Hello, Thanks in advance for the help teamcity manages the version number, ex: 1.29.0.xxx We create the packages using teamcity, and deploy them to the octopus nuget server a build step then create the corresponding release. for the latest version (dev branch on git), everything ok the problem is that we have another branch in progress (RC) using a lower release number, eg: 1.28.0.xxxx this is the QA branch, where some corrections are done before going to prod, while in the meantime the d…

[paul.calvert]

The best option would be to move your build number into the semver segment, e.g. 1.0.0.73

Using the --packageVersion argument to specify the desired package and metadata value might work though.

[donny.bell]

Hi @csecharith,

Thank you for getting back to us.

Your best bet is likely to pivot to a Maven versioning scheme, which would allow for more “parts”. You can read more about this here: Maven versions explained - Octopus Deploy

In this case, instead of version 1.0.0+73, you would end up with something like 1.0.0.73.

Depending on your setup, you may need to adjust the Release Versioning Template to include the 4th section. You’ll find these options in the Settings section of Deployments inside a Project. Here is an example that will increment the 4th section each new release:

#{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.LastPatch}.#{Octopus.Version.NextBuild}

Example of where to find this option:

I hope you find this information helpful. If we can assist with anything else, please let us know.

Best Regards,
Donny