[Development] Branch for Qt 6

Oswald Buddenhagen oswald.buddenhagen at gmx.de
Tue Jan 15 14:30:25 CET 2019


> > On 15 Jan 2019, at 13:44, Kari Oikarinen <kari.oikarinen at 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.
> > 
correct, with a proper wip/ prefix.

> On 15 Jan 2019, at 13:52, Lars Knoll <lars.knoll at qt.io> wrote:
> > Yes, that’s what it would be in practice.
> 
so why are you "abstracting" it? to confuse the reader?

On Tue, Jan 15, 2019 at 01:00:50PM +0000, Tor Arne Vestbø wrote:
> 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).
> 
true, but inconsequential for all i can tell.

> If we already know we’re going to release Qt 6, we can skip the
> feature branch and just set up the branch matching the long term
> solution _now_.
> 
do be clear, you're advocating for permanently doing away with the 'dev'
branch, yes? this pattern does have some appeal, and in fact a few
"peripheral" repos have been operating in this mode for several years
already.

consider these consequences: creation of stable branches is put upside
down, because now it's the next feature branch instead of the
stabilizing branch that gets created. people won't accidentally submit
fixes for dev, because they need to consciously decide the branch
anyway. more feature changes will need retargeting (when they miss the
deadline, possibly repeatedly). related to that, feature freeze will be
probably yet harder to enforce. changes of plan are limited, because one
can't spontaneously create unstable 5.16 from dev when it wasn't there
and all features already went to 6.0. many scripts and processes will
need adjustment. soft branching stable branches would be unnecessary,
but that would also make it inconsistent with release branches. maybe
more ...



More information about the Development mailing list