Channel Version Rules, build metadata

For channel version rules, according to the docs it should only filter based on tag. It seems that it also includes the build metadata.

For example the example rule ^$ for non-prerelease packages does not accept a package versioned as 1.0.0+build.20.

Is that intentional?

Hi!

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

Hope that helps!
Mike

Hello,

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.