[Releasing] ODP: rethinking the branching scheme

[Oswald Buddenhagen]

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.
> 
yes, so?

> 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 fetch
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).