Proposal for branching policy towards KF5

[Albert Astals Cid]

El Divendres, 19 de juliol de 2013, a les 00:21:21, David Faure va escriure:
> 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.

>From a "creating tarballs perspective", it is not a problem (it may need some 
adapting to our scripts but it won't be more work than creating the fake "fat" 
tarballs from all the split tarballs we where doing for some of the releases)

Cheers,
  Albert

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