Proposal for branching policy towards KF5

[David Faure]

After more live discussion with Sebas and Marco plus Aaron over a video chat, 
we came up with the following setup for the workspace repos (*) :

- the development branch for their next feature release (based on Qt5/KF5) 
will be "master".
- *before* this happens, however, kdesrc-build / kde-build-metadata / 
projects.kde.org will need to be improved so that tools (kdesrc-build and 
possibly build.kde.org) can automatically select "the latest Qt4-based branch"
(i.e. master everywhere and 4.11 for the workspace repos), on demand.
This would also be the opportunity to implement "latest *stable* branch" which 
is 4.11 for most modules right now, but could be at some point 4.12 for most 
and 4.11 for workspace repos.
Adding a similar generic selection for qt5/kf5, we would end up giving 3 
options to people who compile from sources: stable, latest-qt4, or qt5/kf5-
based.

I see this as kind of layer on top of the actual branch names (an indirection, 
in other words).

This gives us consistency for everyone:
* for contributors to a specific module, "master" is where new features should 
go
* for people who compile many modules that are supposed to be working 
together, a "logical selection layer" can be selected, stable, latest-qt4, or 
qt5-kf5.

What's not consistent is that kdelibs uses a different scheme for now, but if 
the workspace workflow experiment shows to be a success, which also means the 
tools work well with that, we can switch kdelibs to the same solution later. 
(and the apps even later).

<implementation>
Michael: I see two ways this could be done in kdesrc-build. Either with the 
selection layers being defined by the projects XML and some additional magic 
in branch selection to allow for these new names, or with a much more low-tech 
solution: 3 available files to include from kdesrc-buildrc, like we did with 
kf5-qt5-build-include, except that these files would only contain module-
options (yet another reason for that feature to exist), not actual module 
definitions. The user's kdesrc-buildrc would still define which module he/she 
wants to build, but the included file would define which branch should be used 
for each module (unless overriden, of course).
</implementation>

At this point I think this still needs a green light from the release team, 
though.

To be clear: this means no kde-workspace 4.12, only 4.11.x with increasing 
values of x. Maintainance mode, much like KDE 3.5.x went.
If everything works ok, we could switch kdelibs to that too, as was originally 
the plan.

(*) kde-workspace, plasma-frameworks, please complete this list if there are 
more.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5