Hi Tristan, Love this proposal, +1
On Thu, Jul 20, 2023 at 4:22 AM Tristan van Berkom <[email protected]> wrote: > <snip> > And as this is the first feature addition BuildStream 2.x release, it > presents an opportunity to break away from the versioning scheme > inherited from our origins in GNOME, which I have to reluctantly agree > is confusing and not what people expect from a semver versioning > scheme. > > I.e. currently: > 2.1.x = development snapshots leading up to a 2.2.0 release > > But it would be nice if the next feature adding release was: 2.1.0 I concur. > And that a dev snapshot leading up to 2.1.0 would be 2.1.0-dev0, > and -dev1, -dev2 etc ... in the case that we do want to release > dev snapshots, this follows the format generally used for python > prereleases. > > Please let me know your thoughts on this change. I think it'll be ideal to not have to do, let's say "creative munging" of tags, before uploading the snapshot/development releases to PyPI. This was needed to have something like 1.95.0 pretend to be something like 1.95.0-dev0. So tagging such releases already with the `-dev` suffix makes a lot of sense to me. But... having said that and looking this comment below, I'm now a bit suspcious if our pipeline is currently doing the right thing: > * CI release workflows > > The release workflow is triggered on the '*.*.*' glob match on pushed > tags, so this does not prevent the automated releases to occur on dev > snapshots. > > This requires no changes as far as I can see, the "-devN" standard > for python will allow people to test development snapshots with > `pip install --pre BuildStream` automatically, as documented here: Unless I am missing some nuance here (which is very much possible these days) this glob also means that our snapshot releases (under the old scheme) will also be uploaded as "normal" releases. Let's say we don't go ahead with this proposal for whatever reason, I think this globbing may need to be adapted to deal with the fact that it shouldn't upload the odd-numbered minor releases to PyPI as-is. As there won't be anything distinguishing them from the actual produciton releases. Please let me know if I missed something here. Otherwise I think we should avoid tagging any odd-numbered minor releases until this is addressed. A bit of aside: while Python ecosystem does recognize -dev suffix as special, SemVer also defines the notion of pre-production releases in general [1]. If this proposal goes ahead, I wonder if we can generally claim that BuildStream follows SemVer? (unless of course folks have any reservations against SemVer :) Thanks, Chandan [1]: https://semver.org/#spec-item-9
