[Development] Notes on "Managing Qt's branches" session @ QCS 2016
cavendish.qi at gmail.com
Thu Sep 8 07:37:28 CEST 2016
On 7 September 2016 at 08:37, Friedemann Kleint <Friedemann.Kleint at qt.io>
> the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches
> * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of
> ** Strain on COIN which also has release branches
> ** Merging becomes increasingly difficult
> ** Hard to manage for individual developers
> * Branches
> ** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
that? 5.7.1 is very soon in a few weeks. There will be a few months gap
between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
sometimes it's not tested enough in user(or application developers) side,
so some regressions or a bit critical issues will be found between 5.8.0
and 5.8.1. It's good for users to have a more stable release of 5.7.2.
If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
And I would like to see it becomes a convention for future releases.
> ** After 5.7 is closed and sanity bot is upgraded (to handle
> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> verify source ("cherrypicked from") the SHA1
> ** In the future, exact time for closing stable branches will be discussed
> for each one individually
> * Submit Policy
> ** Target which branch?
> ** Long Term Support (5.6) Branch
> *** Initially equal to stable, increasingly strict over time: Fix only
> severe issues, avoid regressions.
> *** Bugs: For example, P2 for the first year, P1 for year 2, rest
> Security. Try to further objectify that: Jedrzei + Friedemann
> *** Tests: Fix/stabilize tests itself, add tests
> *** No performance improvements unless really significant
> (relevant/reduces O(n))
> *** Upgrading 3rd party (including WebEngine)
> *** Support new OS versions unless introducing new platforms, no rewrite
> of QPA
> *** No cleanups, positively: -> dev
> *** To aid customers with issues, patches for issues in LTS to be locally
> applied can be provided, but the fixes will be pushed to higher versions of
> Friedemann Kleint
> The Qt Company GmbH
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development