On 11 April 2017 at 12:14, Marc Mutz <marc.m...@kdab.com> wrote: > On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote: >> To elaborate: I run a bleeding-edge compiler. It feels odd to me that >> the best branch to run it on >> is a non-bleeding-edge branch, it's quite the opposite. > > I know GCC works differently, probably because you use a RCS that sucks at > merging, but the Qt way was, and continues to be, to put (important) bug-fixes > (incl. compile-fixes) into the stable branch, and merge them up. This is how > Git works best, and apart from LTS, we strongly discourage cherry-picking. The > problem at hand is now whether 5.8 continues to be the stable branch, even > though no release is planned from it.
Well, the way GCC works may be due to hysterical raisins; today almost all of its developers use git, but it's unlikely that they would change the way they work. Why? Because the way things are done in GCC, trunk always gets every bug fix and also works as the first line of defense against regressions, and the released-branches are less likely to break, because not everything under the sun is pushed there. That sort of a model makes perfect sense to me (and I claim that's not just because I'm used to it, I say it *makes sense*), whereas the Qt model gets some getting used to. You say we discourage cherry-picking. Why? Is that not a fairly natural way to backport bugfixes from a bleeding-edge branch to a stabler branch? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
