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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5