semver pattern 1.0.x admits the version 1.1.0-prerelease

[squaremo]

The library used by source-controller for semver ranges includes prereleases in ranges, unconditionally. That is, the range 1.0.x includes 1.1.0-prerelease; and worse, there's no syntax for excluding prereleases.

This is not the behaviour expected or wanted -- you would expect 1.0.x to mean "all patch releases of 1.0". Failing that particular pattern working, you would at least want some way of expressing the latter, but there is none.

I suggest either 1. using Masterminds/semver (with strict parsing); or, if there are just too many problems with that, forking blang and merging the PR that fixes ranges; or failing that, filtering prereleases before comparing them to the range (with, I suppose, the option to include them). The latter really should be implicit per the pattern, but it can at least be a sensibly defaulted option.

[squaremo]

[Including prereleases] really should be implicit per the pattern, but it can at least be a sensibly defaulted option.

It's actually not easy to have syntax for this. Prereleases are sorted lexicographically, e.g., 1.1.0-alpha < 1.1.0-beta, so including a prerelease token for the purpose of implicitly allowing prereleases means you have to find one that will be greater (less than) anything you'll use. For example, if you wanted 1.1.x including prereleases of 1.1.0, you would have to do something like >= 1.1.0-0 < 1.2.0, with the -0 being "less" than any prerelease token you will use. If you want everything up to the next release, you have to come up with a token that will be more than anything that will be used -- say, 1.1.0-zzzzz. This is pretty awkward!

On the other hand, having a flag separate to the range means you can't have complex constraints that include some prereleases and not others. For example, you can't express "every release >= 1.2.0, up to prereleases of 1.4.0".

[hiddeco]

1. using Masterminds/semver (with strict parsing);

Had another look at the problems we encountered using Masterminds/semver over the weekend, and they all seem to be related to using the non-strict parser. Given this, and while taking into account that the format used for ranges is more commonly known, I am now in favour of this change.

It creates a small problem with the parsing of Git tags however, as they are often prefixed with a v, which is a format not supported by the strict parser. I do however think that this is easier to work around (by creating our own "forgiving" parser that just accepts v-prefixed semvers), than making modifications to blang/semver.

[stefanprodan]

I'm ok with using Masterminds/semver#StrictNewVersion, this means creating our own parser that accepts the v prefix but removes it before calling StrictNewVersion.

[hiddeco]

Taken care of in release v0.2.x.