Thanks for getting in touch! This is interesting - after debating it we deliberately made the choice to include metadata so you can actually use it in the Channel Version Rule RegEx filter. We use GitVersion which puts the branch name in the metadata which can be really useful for Channels. Based on a pure interpretation of SemVer, there was also a strong argument to ignore metadata, since it’s just metadata, until it’s not!
public static bool SatisfiesPreReleaseTag(SemanticVersion version, Regex preReleaseTag)
{
if (preReleaseTag == null)
return true;
// For SemVer 2.0 versions, the regex is applied to the PreRelease component and the metadata (including the '+')
return preReleaseTag.IsMatch(version.Release + (version.HasMetadata ? "+" + version.Metadata : ""));
}
I’ve added a GitHub Issue to make this more clear in our UI and docs, and to consider different UX and adjustments to the API to make it all sooo much easier: https://github.com/OctopusDeploy/Issues/issues/2833
In the meantime you’ll probably want to either:
exclude the version metadata component from your package version - do you actually derive value from this? Can it just be part of the .NET Informational Version?
craft your regex to ignore the + and everything afterwards knowing the metadata is included in the filter
Thanks for the information. We have in fact solved this by adjusting the regexes to also allow our (predictable) build metadata, so it isn’t a big issue. I was just wondering if it is a bug or not.
The build metadata in our case is relevant only for informational purposes, especially in development builds (build number increases even though minor version still doesn’t because the feature is still under active development). We will look into other ways we could provide this information, but for now the way it works is fine.