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

[Chandan Singh <chandan chandansingh net>]

Hi  Juerg,

Thanks for having a look.

On Thu, Sep 12, 2019 at 8:25 AM Jürg Billeter <j bitron ch> wrote:
> 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.

Agree. 1.90.0 seems fair to me.

> 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?

The `.devX` suffix signifies a pre-release. Standard tooling like
`pip` understands this, and doesn't install them by  default.

If we don't have such a suffix, then any unsuspecting users who run
`pip install buildstream` will get this pre-release version without
any warning.

With the suffix, they'd have to explicitly opt-in by specifying
`--pre`  flag to `pip install`.

The above is assuming that we publish the development snapshot on
PyPI. I think that's useful especially because we have external
plugins now. Being able to pin them to a tag will be a nice
improvement over current workflows, where BuildStream has to be
installed from git unlike all other dependencies.

Regarding tooling that compares version number, that's a valid point.
Are you concerned about tooling in this repository or elsewhere?
Things in this repository should be easy enough to fix.

It's worth mentioning that anyone using PEP 440 compliant tooling for
parsing versions shouldn't have troubles with this. For example, most
Python tooling (including setuptools) uses the packaging module [1],
that will separate the base version and the  pre-release tag. An
example below:

    >>> v = pkg_resources.parse_version("1.90.0.dev1")
    >>> v.base_version
    '1.90.0'
    >>> v.is_prerelease
    True

> > 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.

Exactly my thoughts. Unless anyone objects, I will change this setting
later today - who's allowed to push - from "maintainers" to  "no one".
This will mean that all changes will have to go via merge requests. As
that's already the norm, nothing should change for developers working
on BuildStream.

Laurence, If I understand correctly, this shouldn't affect the actual
list of maintainers. So, I'm not sure if we need to regenerated the
commiters list because of this change. But please let me know if I'm
missing something.

Thanks!
Chandan