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

Tuukka Turunen tuukka.turunen at qt.io
Mon Apr 16 08:59:36 CEST 2018


I very much like continuous flow of snapshots. Sometimes we have a tendency to fall into a "let's wait and get still this one fix in" mode, which is very inefficient. It is beneficial when making .x patch releases and the fix is for a regression. But in other situations, it is typically more important to have a frequent flow of releases. From that viewpoint I support what Jani proposed. Every period of wait we add makes the release process: 1. longer and 2. unpredicted. We should aim to make the process of creating a new feature release of Qt faster than it is today, so challenging the current process is a good thing. 

We are working on enabling regular snapshots from dev, with target of moving more development and interoperability testing to dev (and thus adding the maturity of dev, making it easier to develop with etc). After these are in place, we have snapshots rolling from all branches of a release. 

With dev snapshots in place, I agree with Jani and think we could:
- Discontinue the concept of an 'Alpha' release of a new Qt version starting from Qt 5.12 (in a way every dev snapshot is a pre-release of Qt 5.12)
- After branching to 5.12, call the first released snapshot Qt 5.12 Beta 1 (or use build number)
- After branching to 5.12.0, call the first released snapshot Qt 5.12 RC 1 (or use build number)

With this we would focus the activities more into moving to a new branch - and of course keep (and even improve) the existing criteria when we are ready to branch. Use of build numbers instead of Beta 1 etc is also fine for me, if preferred.



´╗┐On 16/04/2018, 9.44, "Development on behalf of Simon Hausmann" <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of Simon.Hausmann at qt.io> wrote:

    Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA.
    Unless of course the task of assigning the fix version field was automated.
    On 16. Apr 2018, at 08:12, Alex Blasche <alexander.blasche at qt.io> wrote:
    >> -----Original Message-----
    >>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
    >>> And at this same time I want to propose that we stop delivering alpha
    >>> or beta releases and just do snapshots instead. Publishing regular
    >>> snapshots should be done until we are ready for RC. That because I
    >>> don't see that much need for those anymore. Those are nowadays kind of
    >>> milestones and in my opinion makes whole process a bit
    >>> unclear/difficult (we don't have very good definitions for Alpha and Beta
    >> releases).
    >> Yes we do.
    >> Alpha means feature complete, asking for feedback on the API and new
    >> functionality.
    >> Beta means implementation complete, asking for feedback on the quality of the
    >> implementation, seeking bugs and regressions to be fixed.
    >> RC means we've fixed everything we knew.
    > I wholeheartedly agree with Thiago. The distinction may not make a difference from the release team perspective but it makes a world of difference for developers (who have different limitations for each step) and the world as they can decide how bleeding edge the code is that they want to test.
    > I have a problem with the motivation behind this suggestion too (don't understand it). The naming makes no difference for you as release manager (afaict just a label). Why suggesting it aka what do you want to gain by doing snapshots only?
    > --
    > Alex
    > _______________________________________________
    > Development mailing list
    > Development at qt-project.org
    > http://lists.qt-project.org/mailman/listinfo/development
    Development mailing list
    Development at qt-project.org

More information about the Development mailing list