Hi,

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.

Yours,

                Tuukka

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

    Hi,
    
    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.
    
    Simon
    
    On 16. Apr 2018, at 08:12, Alex Blasche <alexander.blas...@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@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
    

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to