[Development] Qt branches & proposal how to continue with those

[Oswald Buddenhagen]

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.