Hi,

Of those 2a and 2b sound the best to me, however we should be able to make 
5.10.2 at least in case needed on top of 5.10.1 with a critical security fix 
(or similar).

I think keeping 5.9 open a bit longer has benefit due to it being an LTS. It 
adds a bit merge effort, but should be manageable if 5.10 is out of the 
picture. We should aim to increase stability, as is the target of strict mode. 
Perhaps we could simple agree to now on push only items that match strict mode 
criteria to 5.9, rest goes to 5.11 or dev? Move to cherry pick mode for 5.9 a 
few months later then.

Yours,

        Tuukka

´╗┐On 01/02/2018, 16.53, "Development on behalf of Oswald Buddenhagen" 
<development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
oswald.buddenha...@qt.io> wrote:

    On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
    > So based on this Qt 5.9 should be in cherry pick mode next week. With
    > previous wording it should have been in cherry pick mode from 2.9.2017
    > onwards, which was way too soon (hence the change to QUIP5).
    > 
    right.
    
    > What about Qt 5.10.2? This of course needs to be addressed after we
    > see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
    > release, I would like to put full focus into getting Qt 5.11.0 out
    > quickly and try to release Qt 5.11.1 in June already. 
    > 
    yes, but the point is that we can't change the policy retroactively. if
    5.10.2 is an option, then 5.10 needs to stay open as the default target
    for fixes, and be forward-merged. this leaves us at two merges for a fix
    to reach dev.
    the same delay would occurr if we closed 5.10 and continued to merge
    from 5.9, which is why the discussion which one is more important
    emerged.
    
    this leaves us with three options:
    1)
      - 5.9 goes to cherry-pick mode, essentially now.
      - 5.10 stays open until 5.11.0 is released.
        - we should create 5.10.2 before the 5.11.0 release even if we don't
          intent to actually make a release, just so we have a mergable
          target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
          cherry-picks).
    2)
      - we just declare that there won't be 5.10.2 and close 5.10 after
        5.10.1. potentially not user-friendly, but we've done it in the
        past, and while releasing capacity isn't the limiting factor now,
        forward-merging apparently is.
      2a) we continue to forward-merge from 5.9.
      2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
    
    note that 5.10 going to cherry-pick mode is specifically not an option,
    as stated previously.
    
    1) seems most natural to me.
    _______________________________________________
    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