Support SemVer 2.0.0 for Channel Version Range, with regex to match build metadata
Semver 2.0.0 support has been added to Octopus, now supporting both pre-release tags and build metadata, e.g.
2.0.0-pre.release+build.info
However Channel Version Range matching has not been expanded to also support SemVer 2.0.0, and still only allow matching on SemVer 1.0.0 components, the version number (range) and pre-release tag (regex).
I suggest you add SemVer 2.0.0 support to Channel Version Ranges, adding a second regex to optionally match on build info.
The will enable users to automatically select and restrict the correct deployment Channel for the type of build.
Use case 1: We have some projects that use opinionated frameworks that just love to bake in environment configurations as part of their build process. 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
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.
Use case 2: We have Kubernetes clusters with both Linux and Windows nodes, building services requires different build configurations and dependencies, and so we have two configurations of each release that differ only by the build information.
1.2.3+win64
1.2.3+linux
Use case 3: We have nodejs serverless functions that we want to deploy across Lambda, Knative, Azure Functions. The same functions can be written to run in all three, but the build packaging needs to be different. 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+lamda
1.2.3+azure
1.2.3+knative
In discussion it was suggested to append the build configuration information on the package name rather that to the SemVer. However that mixes two concerns into the one field, that isn't even part of the version. SerVer 2.0.0 introduces a way to do this properly, and Octopus should ideally support that best practice.
Ref: https://octopus.com/docs/deployment-process/channels#Channels-VersionRange
Ref: https://semver.org/#semantic-versioning-200
Ref: https://help.octopus.com/t/can-channel-version-rules-match-on-build-information/23370
