[Releasing] [Development] Proposal to adjust release candidate process

Mon Mar 27 12:52:27 CEST 2017

+1 from me to this improved approach

--
Tuukka 

On 27/03/2017, 12.40, "Development on behalf of Jani Heikkinen" <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of jani.heikkinen at qt.io> wrote:

    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
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development