On 7 September 2016 at 08:37, Friedemann Kleint <[email protected]> wrote:
> Hi, > > 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 > problems > > ** 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. Best Regards, Liang > ** 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 > Qt. > > > Regards, > Friedemann > > -- > Friedemann Kleint > The Qt Company GmbH > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
