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...@qt-project.org> on behalf of Tuukka Turunen <tuukka.turu...@qt.io> Sent: Tuesday, January 03, 2017 10:02 AM To: Simon Hausmann; Thiago Macieira; development@qt-project.org; releas...@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...@qt-project.org] On Behalf Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02 To: Thiago Macieira <thiago.macie...@intel.com>; development@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...@qt-project.org<mailto:development-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> Sent: Friday, December 23, 2016 4:42:12 PM To: development@qt-project.org<mailto:development@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@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
