Release Team BoF Summary

[Michael Jansen]

On Saturday, July 14, 2012 12:07:31 PM Jorge Manuel B. S. Vicetto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 14-07-2012 10:29, Michael Jansen wrote:
> > On Friday, July 13, 2012 02:31:35 PM Aurélien Gâteau wrote:
> >> Le jeudi 12 juillet 2012 20:43:12 Albert Astals Cid a écrit :
> >>> So here comes the summary of the Release Team BoF, the attached
> >>> picture is all we wrote during the BoF itself so all written
> >>> here is me trying to remember what we said, if any of the
> >>> presents disagrees or remembers more, please do not hesitate to
> >>> comment.
> >> 
> >> Something which we discussed in the KDE Quality BoF and is of
> >> interest to the KDE Release Team is the numbering of unstable
> >> versions.
> >> 
> >> Up to now we have been using 4.N.8* and 4.N.9* for alpha, beta
> >> and rc. The problem with those is it is difficult when you get a
> >> report on 4.8.85 to know if the user is running beta1, beta2, rc1
> >> or something else.
> >> 
> >> To address this we proposed the following numbering scheme:
> >> 
> >> 4.N.7{1,2,3} => N+1 alpha 1, 2, 3 4.N.8{1,2,3} => N+1 beta 1, 2,
> >> 3 4.N.9{1,2,3} => N+1 rc 1, 2, 3
> > 
> > Why not marking an alpha, beta and rc as what it is and every other
> > project out there already does? Why masking is as a stable
> > release?
> > 
> > 4.N.1~alpha1 4.N.1~alpha2 4.N.1~beta1 4.N.1~beta2 4.N.1~rc 4.N.1
> > 
> > Which btw. was discussed on this very list. So i would like to know
> > what the rationale behind this scheme is. Why keep doing it?
> 
> Both proposals are fine for us (Gentoo).
> 
> Mike, I assume in the above you meant to say given a release 4.N, the
> versions of the new release will be:
> 
> 4.(N+1)-alpha1
> 4.(N+1)-alpha2
> 4.(N+1)-beta1
> 4.(N+1)-beta2
> 4.(N+1)-rc
> 4.(N+1)

Yes.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120714/85eddca5/attachment.html>