Re: [BuildStream] Proposal: More development snapshots, more often

[Jürg Billeter <j bitron ch>]

Hi Chandan,

On Thu, 2019-09-12 at 01:36 +0100, Chandan Singh wrote:
> Since BuildStream's development branch hasn't had a release in some
> time, the list of changes is already very long. And now is as good as
> time as any, so I was think to make our first development snapshot
> about now.
>
> Before making a release, I wanted to tidy up the NEWS file a bit -
> organize it by topics to make it more disgestable, sort by prioity
> etc. I did that in this commit -
> https://gitlab.com/BuildStream/buildstream/commit/108a38edd86d9de3ef0ce78cb005041662ed279e.

The grouping and sorting definitely make this more readable, thanks.

> Another thing to decide how we want to version them. Currently I've
> named the release `1.3.1.dev1`. The `.devX` suffix is the way PEP 440
> recommends to mark developmental release. For the first half, i.e. the
> version string, do we want to stick with 1.3.1 or call it something
> like 1.99.1?

As we already have 1.4.x releases we should definitely use a higher
version number for the development snapshots. I'd suggest 1.90.0 as I
expect this to be clear to many to be a development release ahead of
2.0. It also leaves ample room to 1.99.x in case we want to increment
the minor version. E.g., we might decide on a stabilization phase
before 2.0 and start with 1.99.0 for the first release candidate.

We haven't used `.devX` suffices so far. While I don't expect many
users to confuse 1.90.x with stable releases, a clear suffix would
definitely help for post-2.0 development releases such as 2.1.x. Not
everyone is familiar with the odd-even version number approach or it
may not be clear to all users that BuildStream follows this approach.

On the other hand, completely following PEP 440 would actually mean
that the version number should be something like 2.0.0.dev1, which
would be a larger change from the current scheme. This might also break
scripts or code that compares version numbers.

I'd be in favor of using 1.90.x without suffix for the next development
snapshots as that should be clear enough and discuss a possible change
in version scheme only for post-2.0.0 development snapshots (or
possibly for 2.0.0 release candidates).

Or do we need the dev suffix in the tag for PyPI?

> Sorry again for the accidental push to master.
>
> For most of the repositories I work with, no one is allowed to
> directly push to the master branch. That's not an excuse but I wonder
> if it would make sense to do the same for this repository as well? If
> nothing else, that might prevent such accidents.

This probably make sense. Right now push to the master branch is
allowed for users with the 'Maintainer' role (GitLab default, afaik),
i.e., the branch is only protected for users with the 'Developer' role.
The need to push without merge should be extremely rare (broken CI) and
in that case we could still temporarily unprotect it for a particular
user.

Cheers,
Jürg