[Development] Qt 5.12 schedule proposal & proposal for release process change

[Jani Heikkinen]

> -----Original Message-----
> From: Alex Blasche
> Sent: maanantai 16. huhtikuuta 2018 16.47
> To: Jani Heikkinen <jani.heikkinen at qt.io>
> Cc: Qt development mailing list <development at qt-project.org>
> Subject: RE: [Development] Qt 5.12 schedule proposal & proposal for release
> process change
> 
> > -----Original Message-----
> > From: Development [mailto:development- Keeping release tags is OK for
> > me. Motivation behind my proposal was to stop planning other release
> > dates than FF & final target. Currently we are trying to estimate also
> > alpha, beta and RC release dates and it seems to cause some delays for
> > us: persons aren't fixing blocker issues or doing the test because it
> > seems there is a time to do that later (because e.g RC date is planned
> > to be after a month). So if the way to go is to do these "releases"
> > immediately when ready it might help us to get fixes in earlier and so on
> also get releases out quicker...
> 
> At large I agree with Frederik. The bug side of thing (which delays) we could
> handle in a flexible manor exactly as described by Frederik. I do like to
> emphasize though that the dates for first beta and first RC are important
> (and FF is alpha) because they define times when certain level of changes are
> no longer permitted (e.g. after first beta no API changes). Therefore, you will
> not get around setting a target date for first Beta and RC.

I have to disagree a bit: Alpha and beta phases are important and schedule for FF (and Alpha) as well. But for beta and RC we really don't need it: After API review is done we will enter in beta phase (and at this same time beta1 is released). And we should release RC when all blockers are fixed.  If we schedule the RC beforehand it seems to affect how developers are prioritizing their work. And that's why I think we shouldn't even estimate when the RC is going to be happen: It is released when we are ready for it.

So  I think the way to proceed with this should be like Lars proposed:
- Snapshot packages from the dev branch
- FF and branching occur together and packages are getting the ‘alpha’ tag
- Agree that we should start with the API review immediately.
- Beta once API review is done. Lets agree the 'Done' properly to get it clear for everyone. I already tried to start discussion about it in http://lists.qt-
> project.org/pipermail/development/2018-March/032338.html
- RC once we have the release branch and all currently known blockers are fixed

br,
Jani



> 
> --
> Alex