Create Release not triggered due to conflicting existing release version

reliability
(Koms) #1

image

Hello Team,

I could not get my release created automatically due to a conflicting version.
Eg. For a release version

3.0.0-beta.10 --> 3.0.1 (next auto-generated version)
3.0.0-beta.11 --> 3.0.1 (should be the next version, per Octopus default Release versioning rules)

3.0.1 (next version) ← Because this is not possible since 3.0.1 release version already exist, octopus failed to create an auto-generated release, and didn’t give any error too.

Also, after removing release with version 3.0.1, and again triggering new release automatically, this time I could get new release 3.0.1 created after 3.0.0-beta.11
3.0.0-beta.11 --> 3.0.1

My question is -
This versioning seems conflicting. What can be done as deleting an old release so that new release can get created doesn’t look appropriate. Please suggest. Have attached screenshot for reference

(Kenneth Bates) #3

Hi @Koms,

Thanks for getting in touch! I’m sorry about this unexpected behavior you’re encountering. I’ve reproduced this where the last release (latest by creation time, but not latest by version number) will dictate how the next release is versioned. This seems to be due to the special variables as defined in your project’s settings (default template is #{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.NextPatch}) and these pull values from the last release by creation time and not by version number.

We agree this behavior should probably be changed so I’ve raised the following bug report for you to track.

If you’re using a package step in this project, potentially the best way to permanently work around this would be to configure your project to version its releases based on the included package’s version. Would that help in your scenario?

I appreciate your report! Let me know how you go or if you have any further questions going forward. :slight_smile:

Best regards,

Kenny

(Koms) #4

Thanks Kenneth for the prompt response.

I think the issue i am facing is more related to two Release versions getting evaluated to same next release version, hence dont seem to be a release creation timing issue that is being reported here

i.e.
3.0.0-beta.10 (created manually) , 3.0.0-beta.11 (created manually) both evaluates to --> 3.0.1 as next auto-generated version.

Also, based on guide https://octopus.com/docs/packaging-applications/create-packages/versioning
3.0.0-beta.10 > 3.0.0-beta.9

So it is possible to create incremental releases as 3.0.0-beta.10, 3.0.0-beta.11 but auto-creation of release results to version - 3.0.1 (i.e. only increments patch before (-))

Also, am not sure if our customers configure their projects based on included package version only. Kindly suggest best way to enable auto-increment of next release version.

(Kenneth Bates) #5

Hi Koms,

Thanks for keeping in touch. It looks like the issue here is that since 3.0.1 was created before 3.0.0-beta.11, the release versioning template set on the project, specifically #{Octopus.Version.NextPatch} (being the second 0 in 3.0.0-beta.11) is incrementing this 0 to 1 which then evaluates to a release version that already exists. The issue I raised was to improve the intelligence of this and find the latest patch release instead of the most recently created one, where that improvement I think should fix this issue.

To get around this currently, I think the only way to do so is to use channels, where you create your -beta.# releases into a separate channel. Here you can use channel scoped variables to control how the versions are incremented based on channel. You can see more info here on your project’s settings by expanding the Template variable information as shown below.

template_variable_information
template_variable_information.png2063×1637 149 KB

I hope this helps! Please let me know how you go or if you have any further questions. :slight_smile:

Best regards,

Kenny