Release auto-increment cannot cope with releases with different tags but same semantic versioning

ruf-u
(Steve Marsh) #1

Hi,

We have Team City ‘developer’ builds with independent version numbering, compared to our mainline. Thus, our mainline might produce builds with package versions in the form ‘AA.BB.CC-latest’, and developer A might produce builds with package versions in the form ‘XX.YY.ZZ-developera’

When we generate Octopus releases, we generate builds with semantic versioning AA.BB.CC-prereleasetag.i, where the version matches the package version, and i is the increment operator. The problem we are having is that the use of “i” to auto increment the release (really useful when testing a deployment process) is failing to work as expected when there are different prerelease tags with identical numerical portions prior to the prerelease tag. It seems like sometimes the “current” value for i is not being correctly grabbed during the “create release” process and its trying to create a release with a value of i that has already been used, generating errors such as “Release ‘1.0.39-darrenf.1’ already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.”

In my view the auto-increment should work independently for any given release version, including a prerelease tag (if present).

Not seeing an easy workaround for this given that the releases come from different build chains in TeamCity… other than to force overwrites of existing releases in the event of a clash. (if that’s even possible using octo.exe!)

Regards,

Steve

(Daniel Fischer) #3

Hi Steve,

Thanks for getting in touch! I have spent some time testing the on my end and have reproduced the same error you are seeing. The behaviour seems odd however, as it my testing, I was able to see this error but the release was still created. (I was not able to pass the create release screen but it still showed up under Releases -> 1.0.1-test.x.

I have created a GitHub issue for this as there is definitely a bug here and we should support this without an issue as it is correct SemVer.

Let me know if you have any further thoughts or questions on this.

Best regards,
Daniel