[Releasing] ODP: rethinking the branching scheme
oswald.buddenhagen at digia.com
Fri Feb 21 16:25:17 CET 2014
On Thu, Feb 20, 2014 at 12:22:51PM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 19:27:57, Oswald Buddenhagen escreveu:
> > On Thu, Feb 20, 2014 at 09:30:31AM -0800, Thiago Macieira wrote:
> > > I remember how difficult it was to get KDE developers to update the
> > > branch of Qt they were using whenever the minimum required version
> > > changed.
> > that is hardly related to how hard it is to switch the active branch of
> > a checkout. the time to recompile the thing (and possibly to adjust the
> > configuration first) is what discourages "consumers" from updating. this
> > is not influenced by the branching scheme at all.
> You're missing the point.
> If you're a KDE developer but not a Qt developer, yet you have your local Qt
> build, as many do, you're probably using the oldest Qt that still works. You
> don't build that often. Update reasons are:
> 1) bugfix that you need
> 2) feature that you need (usually requires going to a new Qt version)
> 3) the minimum required version changed
> The difference between 1 & 2 with 3 is that in the first two it's a voluntary
> change. You know you want a new version and you have the time to look for it.
> The latter one is something that gets imposed on you. Things stop building if
> you don't act. So now you've broken your kdecore and kdeui and can't recompile
> until you figure out how to get the newest Qt.
> And, yes, getting people to understand how to create the new branch and check
> it out is not easy. The memory isn't fresh, but I do remember this happening a
> lot in #kde-devel as well as in #qt.
git branch -r # alternatively, ask on irc or find it on a wiki page
git checkout 5.2
given that kde folks work with git every day, i find the argument of
this being "hard" somewhat bizarre.
on top of that, your idea to automatically "force" the latest stable on
the "consumers" has a downside: it makes it actively hard to use the
"oldest version that works" approach (which is a quite reasonable one to
prevent accidentally requiring too new api).
More information about the Releasing