Re: [BuildStream] BuildStream releasing model



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.

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.

I've been wrong before, so please help me understand my errors here...

br
Paul


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]