Future frameworks releases

[Heinz Wiesinger]

On Tuesday 09 June 2015 11:49:55 Christian Mollekopf wrote:
> On Tuesday 09 June 2015 11:16:17 Raymond Wooninck wrote:
> > On Tuesday 09 June 2015 10:50:36 Christian Mollekopf wrote:
> > So all in all, we as packagers trying to utilize whatever we can to ensure
> > that our users are ending up with a consistent set of libraries and
> > programs.
> > 
> > I can imagine that the current versioning of the Frameworks Libraries are
> > not the most ideal ones for the library maintainers themselves, as that a
> > version is updated even when there are no changes. But on the other hand
> > this would increase the consistency between the libraries themselves.  At
> > least for the packagers.
> 
> I just don't think simply ignoring versions by putting on timestamps (which
> is what the current versioning scheme is) solves anything. A lot of work
> has been put into splitting up the frameworks, just to now say we want to
> treat them as a monolithic blob again. I obviously think that splitting up
> was very much the right decision, but the versioning policy really hinders
> the full potential of frameworks as an ecosystem of loosely related
> libraries that can be used by third parties. Instead we again end up with a
> blob where you cannot update one part without affecting the rest of the
> system.

Please be aware that "an ecosystem of loosely related libraries" can have 
largely different meanings depending on the perspective you are using. From the 
perspective of a user of frameworks it's mainly about being able to only 
depend on the parts you actually need, for example, depend on kimap, but not 
kwindowsystem. The release interval is only of minor interest here.
Now, from the perspective of a frameworks developer it might be of more 
interest, but then again the most important thing here seems to be to be able 
to get features/fixes out to the users as soon as possible (hence the monthly 
"timestamping").

Binding the individual libraries to a common release brings many benefits to 
all of them. It brings meaning to the term "KDE Frameworks" beyond the fact 
that it's just a bunch of libraries released together. It gives an impression 
of unity, of trust. "It's part of KDE Frameworks" is a stamp of quality, 
because it implies a set of rules that is followed.

Let's take a look at a similar set of libraries released together, which does 
not have the versioning restriction: X11R7.7. It's a name, at best. A mere 
label for a set of libraries that should work well together, but actually 
nobody cares because everyone uses different combinations anyway. This is what 
would happen to KDE Frameworks if you'd have to handle every library 
individually.

So IMHO, while exceptions on the versioning could be made, I would very much 
lean against that in order to protect the "KDE Frameworks" brand.

> > As Hrvoje indicated a couple of exceptions can be easily handled, but if
> > this would turn out that KDE Frameworks 5.12 would consist of libraries
> > with all different version numbers, then it would be the greatest
> > nightmare
> > for us packagers.
> 
> If managing versions of libraries is the "greatest nightmare" then I simply
> don't understand how any of this works. The complete linux stack consists of
> a variety of libraries that all have their individual version numbers, and
> I don't understand how it becomes so much more difficult just because a
> library is part of frameworks.

It's convenience. With the current packaging the package building can be 
scripted to handle all libraries equally. You define the version once, and have 
an abstract way of recursively building everything that's part of the latest 
frameworks release.
If you have to treat a subset of libraries in a special way, you loose that 
convenience and suddenly maintaining packages for them becomes a lot more 
work. it looks mundane, and in most cases it probably is, but it comes down to 
the fact that assumptions about simplicity can no longer be safely made.

Do note that while a typical linux distribution does ship with an abundance of 
libraries that need to be handled differently, very seldomly those are 
maintained by the same person, while KDE Frameworks in its current packaging 
form can be handled by one person just fine.

Grs,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20150609/0dab8db4/attachment.sig>