> On 15 Jan 2019, at 14:25, Lars Knoll <lars.kn...@qt.io> wrote: > >> >> On 15 Jan 2019, at 14:00, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote: >> >> >> >>> On 15 Jan 2019, at 13:52, Lars Knoll <lars.kn...@qt.io> wrote: >>> >>> >>> >>>> On 15 Jan 2019, at 13:44, Kari Oikarinen <kari.oikari...@qt.io> wrote: >>>> >>>> An alternative way of seeing (and perhaps handling) is in the same way as >>>> we >>>> handle feature branches. The qt6/6/next/whatever branch would be for >>>> development >>>> that can't be put into dev yet as it is not suitable for the 5.x releases. >>>> Everything that is suitable for 5.x would still go to dev. Once the last >>>> minor >>>> version of the 5 series of releases freezes, dev is open for 6.x stuff. >>>> Then the >>>> qt6/6/next branch would be merged into dev and deleted. >>> >>> Yes, that’s what it would be in practice. >> >> Except we can’t merge ‘qt6’ into ‘dev’ until 5.15 has been branched, and >> we’ll branch off 6.0 before that, so unlike a normal feature branch that >> gets merged into a release branch, and then released, we would then release >> directly from a feature branch (qt6). > > Huh? Why? Qt 6.0 would only be branched half a year after 5.15 is being > branched. I don’t see the problem here.
In that case the feature-branch perspective works. I was under the impression there would be an overlap in dev activity. So: - qt6, until 5.15 is branched, then merge qt6 into dev, delete qt6, and branch 6.0 off of that? Sounds good, though I agree with ossi it should be wip/qt6. My main motivation was that we wouldn’t lave a long term ‘qt6’ branch. And if we happen to do a 5.16, it would be branched off 5.15, since there’s no more Qt 5 series dev as ossi pointed out. Tor Arne _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
