[Development] Proposal to adjust release candidate process
Simon.Hausmann at qt.io
Fri Dec 23 14:27:30 CET 2016
I find that the branch is relevant in this context, as it relates to the amount of patches going in. The amount of patches going in is IMO related to the probably of introducing regressions. The process around the release branch, as opposed to the "minor branch", as proven to be a useful mechanism for reducing the churn and making people ask themselves: Do I really want this change in this release or can it wait?
So from what I think is one metric of quality (not the only one of course), the naming of release candidate is more meaningful.
From: thiago.macieira at intel.com
Sent: December 23, 2016 14:20
To: development at qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process
Em sexta-feira, 23 de dezembro de 2016, às 07:17:01 BRST, Tuukka Turunen
> > Call it beta 2 (or gamma 1) right after branch and one we've iterated and
> > we could have released, we call it release candidate. We release them
> > more often, with more iterations, so that we get more feedback. I think
> > that's the most important part.
> Beta 2 is still a bit misleading in my opinion. It is coming from release
> branch, so we are beyond the Beta phase. Let's think about the name later,
> after the holidays. It anyway seems that the basic approach is seen viable.
The branch it comes from is irrelevant. If it's after Beta 1 and is not RC
quaity, then it's still a Beta and the next number available is 2.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development