Hi, we have some projects that use opinionated frameworks that just love to bake in environment configurations as part of their build process. It blows IMHO, but it is also ubiquitous with some frameworks cough Angular cough
As a result we have some packages where the SemVer differs only by the build information, based the environment it was built for, e.g. 1.2.3+abcd123.europe and 1.2.3+abcd123.useast. We would like to use Channel Version Rules to ensure the correct configuration uses the correct Channel only. And to enable the use of Automatic Release Creation.
Our reading of the documentation suggests we can apply a regex match to the SemVer pre-release information but not on the SemVer build information? It that right? If so, we would like to request a second regex is added to the dialog for version rules for matching on build metadata. In that way you have full SemVer coverage.
I realize we could probably fake our way though this by placing the build information in the ‘pre-release version’ slot of SemVer, but that wouldn’t make SemVer sense since these packages are not in any sense ‘pre-releases’.
You are correct - we only support matching on the version number for the range, and on the pre-release tag for the regex. We support the regex on the pre-release tag, as its a common way to use branches.
For your use case, I would suggest using the package name to differentiate the packages:
You could then either use variables to select the package name, or a step scoped to an environment to select the appropriate environment.
As for your suggestion to add support for the build metadata, while I can see the appeal, it’s not something we’re likely to implement, but if you feel that it would gain community support, I’d recommend adding it as a suggestion to our UserVoice site - we use that as part of our prioritization.
I was guessing the current Channel Version Range matching was added back when Octopus only supported SemVer 1.0.0. And it was just never updated when SemVer 2.0.0 support was added. The Channels page doesn’t mention or show any SemVer 2.0.0 examples, and was probably also written back in SemVer 1.0.0 days. So the current limitation may be more historical accident than conscious choice.
Thanks for the suggestion about mushing the build info into the package name. That would work, but it is mixing two concerns, and SemVer 2.0.0 gives us a proper what to express this.
