[Development] Proposal to adjust release candidate process

[Tero Kojo]

Hi,

As someone living quite close to marketing.

A couple of questions.

1.       As the T-4 release is essentially from the start of the 5.n.0 branch, are only fixes allowed there? (no new content, unless for some really weird reason)

2.       Is it possible that the T-4 release could be so good that it would be released? (i.e. no major bugs)

If I understand correctly the answers are 1. yes, and 2. in reality no.

And as we live with the "alpha, beta, RC" - terminology then call it beta 2 (or second beta, in writing the sentence "We are releasing the second beta of Qt 5.n" looks better).
Inventing new names makes little sense, and it isn't an RC if we can't ship it.
Let's not invent new words, or borrow words from other release cycle styles, that just makes for confusion.

Tero

From: Development [mailto:development-bounces+tero.kojo=qt.io at qt-project.org] On Behalf Of Tuukka Turunen
Sent: tiistai 3. tammikuuta 2017 10.02
To: Simon Hausmann <Simon.Hausmann at qt.io>; Thiago Macieira <thiago.macieira at intel.com>; 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<mailto:thiago.macieira at intel.com>>; development at qt-project.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170104/0c08962e/attachment.html>