> > On 15 Jan 2019, at 13:44, Kari Oikarinen <[email protected]> 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 <[email protected]> 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 ... _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
