Thanks for the reply. Not everyone agrees on a the name, but it sounds like Trunk Based Development was/is the model for the 5.x.
To clarify, bug fixes (via phabricator) land in master (the trunk) and were cherry-picked back to the 4.x branch if applicable. I acknowledge that cherry picks are not always possible if things have diverged too far. - Paul On Tue, Feb 28, 2017 at 9:58 PM, Michael Pyne <mp...@purinchu.net> wrote: > On Sat, Feb 18, 2017 at 06:59:41PM -0500, Paul Hammant wrote: > > In 2011, something bubbled to SlashDot from this community. > > > > https://tech.slashdot.org/story/11/08/07/2128222/KDE- > Frameworks-50-In-Development > > > > TL;DR: what branching strategy to adopt for the KDE 5.x work, given > > a wish to: > > 1) stay abreast of 4.x fixes/releases, > > and 2) not make the mistakes of the 3.x to 4.x effort (whatever they > were). > > > > May I ask what actually happened re branching, merging, cherry picks > > (back and forth) and all that, and what veterans think about it all > > looking back? > > For KDE Frameworks my impression is that the branching strategy in git > itself turned out to be anticlimactic. > > Unlike the Linux kernel model (where a commit will filter through many > different git repositories before eventually landing in Linus's > "official" git repo) or the Github model (where a pull request is used > to request review and then merge in commits from an external repo), we > typically review the proposed commit's diff first (with Review Board, > and now Phabricator) and once cleared to land, we integrate it directly > into the appropriate git repos (we maintain a large number of separate > rpoes). > > Since Frameworks is on a single-track, frequent-release model we don't > routinely maintain separate stable and dev branches. So when reviewed > commits are landed in Git, they go straight to master, and the eventual > release is performed directly from master as well. > > This doesn't mean it's impossible to develop a long-running feature in a > separate branch and merge it in later. But since it hasn't been > necessary for development, the 'branching strategy' issue doesn't really > come up here. > > Outside of KDE Frameworks (where we do typically maintain stable and > development branches), both strategies are employed but generally we > make any needed backports in the stable branch and then use a merge > commit to forward-port to master. > > I think the discussion was good to have because it helped shine a light > on some of the factors a git-using developer should consider and helped > us to better use our source control tools. But I don't think it really > impacted that much for our development, at least in comparison to all of > the many other best practices we need to be aware of. > > Regards, > - Michael Pyne >