Why are non-breaking releases increasing the minor version?

[davidanthoff]

Same point as over here.

It seems that the last release (0.21) were really non breaking, right? I think in that case it is really less than ideal to increase the minor version number while we are pre 1.0, because the package manager will interpret these versions as breaking in the semver sense, which makes it cumbersome to properly take a dependency on this package.

I should say that I think everyone's life would be much easier if we just moved to 1.0.0, here and used normal semver rules for version number increases.

[matbesancon]

This is valid, but some things need figuring out before releasing 1.0, if we don't want 2.0 right after it, see the issue on releasing 1.0

[davidanthoff]

I actually don't mind a 2.0 right after a 1.0 at all. I just want an easy way as a depending package to specify my compat bounds.

[matbesancon]

To come back to the initial issue, indeed we could have used a patch for the last release, it just felt "wrong" when huge changes (non-breaking though) are present

[davidanthoff]

See, this is why we should move to 1.0.0 :) Then you can give proper credit to huge changes without creating work for downstream packages :)

[matbesancon]

that's a fair point, I'll close this in favor of #880 where the main 1.0 tracking happens