[Development] Proposal to adjust release candidate process

[Jani Heikkinen]

Hi all,

Ok, I have thought this now a while & discussed internally with Tuukka and few others. I have new proposal which is kind of middle between Tuukka's proposal & current process:

1. From FF to beta we will do things as earlier. Of course we need to find ways to cut the time there but it is different story...
   - Only change is snapshot build distribution via online installer before beta release & beta release as online only (this is already implemented)
2. After first beta release we don't deliver any binary snapshots anymore but do release additional beta releases ~ once per week (with more lightweight process than current releases are done: no blog post from every beta release, limited test round before additional beta N release and full test round when beta N is publicly available, no official approval from release team meetings ...)
   - This is mandatory step now when delivering snapshot & pre-releases via online installer: New snapshot / pre-releases are updates to previous one -> after beta2 is released there is no first beta available via online installer.
3. When beta N is well enough we will create and release RC.
4. If RC seems to be good enough we will release final but if some blocker found during RC testing we will release immediate RC2 (again with more lightweight process) etc..

br,
Jani
________________________________________
From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Tuukka Turunen <tuukka.turunen at qt.io>
Sent: Tuesday, January 03, 2017 10:02 AM
To: Simon Hausmann; Thiago Macieira; development at qt-project.org; releasing at qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process

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.

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