Future frameworks releases
pprkut at slackware.com
Tue Jun 9 13:35:20 UTC 2015
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
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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213 bytes
Desc: This is a digitally signed message part.
More information about the release-team