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.
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.
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?
Is there any other value that we can change instead of patch number?
Can --packageversion argument to the Octo.exe help in this scenario?
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: