SemVer 2.0 with build metadata

Legacy Uncategorised
1

I am not sure if this a bug or a feature.

I upgraded to Octopus 3.4.1 and was able to upload the package Test.Package.1.3.0-alpha.1+35.zip just fine but when when I tried to upload the package Test.Package.1.3.0-alpha.1+36.zip the server told me that “A package with the same ID and version already exists.”.

I read the blog post on the SevVer 2.0 feature and it didn’t mention that packages that differ in build metadata only cannot be uploaded to the server. It only mentioned that the order of such packages is undefined. The “undefined” order raises a question too. If it is indeed possible to upload such packages, how can they be used in automatic deployments?

Thank you,
Rosti

2

Hi Rosti,

This was a bug, thank-you for reporting it.

I created an issue and commited a resolution. It will be part of our next release (3.4.2) which should be available in the next day or so.

Regarding your question about Automatic Release Creation:
You’re correct, this may result in undefined behavior when using package versions differing only by metadata (as ARC will select the latest package versions).
What I would suggest in this case is to not rely on ARC, but rather to explicitly create your releases using either the appropriate plugin for your build server or by using Octo.exe.

SemVer 2.0.0 support is obviously a new feature, and we’re more than happy to work with our customers to support the ways you want to work. If you have any specific issues or further questions, please don’t hesitate to ask.

Regards,
Michael

3

Thank you, Michael!

Regarding build metadata. Yes, SemVer does not specify any semantic meaning for build metadata but would it be a good idea to sort build metadata portion based on, say, simple lexical ordering for utilitarian purposes? This won’t break the SemVer specs but will remove “undefined” workflow link from an automated deployment process.

Rosti

4

Rosti,

You are most welcome. Version 3.4.2 has now been shipped with a fix for that issue.

I will raise this with the team, but one problem is that currently Automatic Release Creation will only fire if the pushed package is the latest version.

So even if we defined lexicographic ordering on the metadata, you could:

  1. push version 1.0.0+foo and ARC would fire
  2. push version 1.0.0+bar and ARC would not fire
  3. push version 1.0.0+qux and ARC would fire again

This behaviour seems confusing. Also, it would feel like a step backwards to see the same lexical work-arounds used on metadata that were used on pre-release versions in SemVer 1. E.g.

  • 1.0.0+0001
  • 1.0.0+0002
    etc.

I guess a follow-on question is whether we should allow ARC on versions that are not the latest…

Personally, I prefer explicitly creating and deploying the release using the API (or more likely via a client such as a build-server plugin) rather than relying on ARC.

Regards,
Michael