Versioning of Frameworks

[Christian Mollekopf]

On Wed, May 6, 2015, at 01:42 PM, Jan Kundrát wrote:
> Hi Christian,

Hi Jan,

> I think that the stuff you're looking for (reducing version churn) can
> also 
> be provided by having stable branches for selected parts of KF5.
> 
> IMHO this can be quite an elegant solution given the usual cat-herding 
> problem of FLOSS where people just do what they want to do. Those who
> value 
> the benefits of having bugfix-only releases and those willing to put
> their 
> time into this could well branch from a random KF5 release and keep 
> backporting bugfixes. I can give you CI coverage pretty easily for this.
> 
> Would this solve this problem for you, and would you volunteer to become
> a maintainer for this? Has this been discussed before, or is there some 
> reason against doing this?

It's unfortunately only part of the solution. Stable branches are indeed
a useful tool
to backport fixes, as long as no new features are required, but they
become increasingly expensive
to maintain (the more master diverges from that branch). So while
they're excellent
to backport a fix or two, they are not the correct solution if new
features are required (or any large patch for that matter).

So on a server where we need use kcalcore through libkolab, as long as
we only need some bugfixes we simply
backport that patch to the relevant branch (say 5.4, bump the patch
version, say 5.4.3 and update just that).
That way we can confidently update knowing precisely what changed.

If we need a new feature, and that's available only in 5.6, we'd have to
do some more testing,
but still, by the nature of these libraries dependencies need very
rarely to be bumped (the functionality provided
is easily implemented on libraries 5 years old), so again, we know
exactly what changed by simply looking at one library.

With current frameworks we'd end up updating from 5.6 to 5.13, and then
pull in changes from all dependencies within
frameworks, unless we essentially fork all frameworks and drop the
dependencies again, which frankly is a waste of
everyone's time and precisely what I hoped to get away from with
frameworks.

So with the way frameworks currently deals with versions it becomes
prohibitively expensive and/or risky
to use it in an enterprise environment, where you sometimes just cannot
afford stuff to break,
which is why I need a solution for this.

Thanks for leading this discussion into a more solution oriented
direction =)

Cheers,
Christian