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

[Shawn Rutledge]

> On 20 Dec 2016, at 14:34, Tuukka Turunen <tuukka.turunen at qt.io> wrote:
> 
>  
> Hi,
>  
> I think we have three major problems with our current release process regarding the release candidate phase:
> 1.       Process to make a RC that is as flawless as final causes inefficiency as we only get full test coverage with the RC itself
> 2.       We get full attention for testing a bit too late, many fixes are still coming in close to the planned RC time causing instability
> 3.       Current time between RC and final is planned to be 2 weeks, which is very little in order to take in the feedback and fix things
>  
> Therefore, I would like to propose the following:
> a.       Consider “Release Candidate” to be a phase rather than an individual delivery
> b.       Create the first “RC1” almost immediately after release branch (e.g. 5.9.0) is operational
> c.       Criteria for the “RC1” is that no known P0 bugs exist (i.e. there can be other issues that would not be acceptable in a final release)
> d.       During the “RC” phase P1 (and possible P0 of course) bugs and documentation are fixed
> e.       Public “RC” release is similar development release as Alpha and Beta in that it starts a phase of work
> f.        Multiple snapshots / new candidates are created during the “RC” phase until one of them is considered the final release
>  
> If desired, we could use some other name than “Release Candidate 1” for the release that begins the last phase of the release. It could be called “Beta 2” or “Technology preview”, if so desired. Personally, I would call it “Release Candidate 1”.
>  
> The difference to our current process is quite small. In essence it would be about considering the “RC1” the beginning of the final releasing phase (.0 branch), not something we do almost at the end of it. I believe that lowering the quality criterial for “RC1” helps us in being more efficient as it has been in practice impossible to really fulfill the current process goal and have already the first RC as good as the final.
>  
> In case of Qt 5.9 it would mean that we have the first “RC” out around end of April, soon after the branching to 5.9.0 has been completed. We then have 4 or so weeks to make all the needed amount of candidates / snapshots until one of them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, great. If it takes more time, then so be it (although in such case we have probably missed something in the earlier steps of the release creation).

+1, sounds good to me.