Re: [BuildStream] BuildStream releasing model

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Tue, 2018-07-31 at 10:18 +0200, Paul Sherwood wrote:
> On 2018-07-31 08:28, Tristan Van Berkom wrote:
> > On Mon, 2018-07-30 at 16:51 +0200, Paul Sherwood via Buildstream-list 
> > wrote:
> > > Hi folks,
> > > as discussed on IRC today (from [1] onwards) I (and others) think 
> > > that 
> > > the BuildStream releasing model is confusing for new users and would 
> > > like to suggest that we change it now, rather than later.
> > >
> > > IIUC understand it Tristan chose the current model because it is 
> > > commonly used in GNOME projects, but I don't think that's a good 
> > > justification.
> >
> > I most certainly did not, I have been using these versioning semantics
>
> My mistake, then, sorry.
>
> > for projects regardless of their association to GNOME, because the
> > even/odd minor point numbering scheme provides context about what is
> > stable/dev, where alternative numbering schemes don't communicate that
> > well.
>
> Please let's not use 'stable' since what engineers typically mean by 
> 'stable' is often not what users expect or need.

I leave Agustin's answer as it is a good one, but note that this is
only a matter of nomanclature.


> Please can someone spell out **the reasoning** for this odd/even model, 
> without digressing to history or references from other projects.
>
> My counter-proposal is:
>
> 1) we tag a release from time to time (frequency tbd... let's guess at 
> quarterly). new users are told to use the latest tag
> 2) after the release we merge some new functionality, test it, fix the 
> breakages, and ensure that we are backwards compatible with content from 
> our previous releases
> 3) we tag a new release
> 4) we tell existing users to migrate forward to the latest release 
> within a time window (tbd, let's say 1 year)
> 5) if we identify crash/security bugs we make them in master then 
> cherry-pick/backport to old supported tags, or state that we have to EOL 
> old tags early
>
> I'm suggesting this to emphasise that I think we should always have one 
> release live, and one that we are working towards, and everything else 
> is secondary.

This is basically exactly what we have, except we have it with branches
and not only with tags.

Now more than every before (and hopefully more than ever in the
future), it is of the utmost importance to give the master/development
branch some leeway for development.

At the current rate that contributors want to develop features, it is:

  A.) Impossible to safely push releases from master onto users who
      need things to "just work" or at the very least not regress.

      Things need time to materialize in master, and branching early
      is a move we did especially to cater to the contributors who
      need more velocity in their development work.

  B.) Also important to provide development snapshot releases from
      the development line, for those users who willingly take the
      risk, play with things early, and help us identify issues
      before landing a new 1.4 that is reasonable usable and does
      not regress compared to 1.2.

This is not extremely complicated to manage, it is all about being
responsible towards users, and also towards contributors who want to
achieve great things.

Cheers,
    -Tristan