[Development] Proposal to adjust release candidate process

[Frederik Gladhorn]

On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote:
> Hi,
> 
> Perhaps it is best to talk with marketing about the name of the "release
> done immediately after branching to the .0 release branch". Reading the
> discussion, it seems that other than the name we are well aligned.

I'd try to follow standards, this is supposed to be primarily understood by 
developers. semver is the most sensible thing I know of when it comes to 
versions. #11 is pretty sensible:
http://semver.org/#spec-item-11

I'll just copy their example and would like us to follow it:
Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-
beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.


I agree with Robin in that we should make it easier to test, so for me the 
priority would be to get nightly builds out there and make it easy to install 
them through the online installer. Currently there is no sensible way for the 
community to help out since all the code and procedures are internal. We're 
cleaning many things up (one problem that The Qt Company has is that we have 
not stream-lined releasing and packaging the different products enough, Qt for 
Application Development and Device Creation for example are not packaged 
completely the same way...).

Cheers,
Frederik


> 
> Our current process has "Release candidate" 2 weeks prior to the Final
> release (see: https://wiki.qt.io/Qt5Releasing).
> 
> If we now have the beta2/preview/othername release 4 weeks before the final,
> our schedule is the following:
> 
> Phase                                              Timing
> Feature freeze                            T-17 weeks
> Alpha release                              T-13 weeks
> Beta release                                 T-8 weeks
> Soft string freeze                       T-6 weeks
> Hard string freeze                     T-5 weeks
> Beta2/Preview/XYZ                  T-4 weeks
> Final release                                T
> 
> In addition to the main phases, there will be snapshots regularly for
> testing. During the final weeks before the release these snapshots are then
> considered as possible final release unless testing reveals a need to
> change something. This part is unchanged.
> 
> The main benefit for the change is providing a very close to final package
> for users to test earlier. During the 4 weeks after Beta there is always a
> lot of improvements, but after branching to the release branch we should
> focus only for the high-priority error corrections and polishing the
> documentation (if not already done earlier).
> 
> PS. I would like to shorten the overall duration of the release creation to
> 12 weeks from FF to final. I think that being more strict about the FF and
> by having all the needed configurations done early enough, we should be
> able to cut the time between FF and Alpha as well as between Alpha and
> Beta. But that is something we can discuss later.
> 
> Yours,
> 
>                              Tuukka
> 
> 
> From: Development
> [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf
> Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02
> To: Thiago Macieira <thiago.macieira at intel.com>; development at qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> 
> 
> 
> Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case
> the branch makes no difference and beta is a better name.
> 
> 
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development
> <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development
> -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Thiago Macieira
> <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> Sent: Friday,
> December 23, 2016 4:42:12 PM
> To: development at qt-project.org<mailto:development at qt-project.org>
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
> 
> escreveu:
> > 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.
> 
> How about this, then? We release beta2 from the 5.n branch right before the
> 5.n.0 branch is created (or finally branches off). It accomplishes the same
> thing that Tuukka wanted: a release containing the code that is in the 5.n.0
> branch at the moment it is created, not a few weeks after with some round
> of work.
> 
> And I really mean "the code that is in the 5.n.0 branch". Since the two
> branches at the same at that point, it's only a semantic difference which
> one we created the beta2 release from.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development