Future frameworks releases

[Christian Mollekopf]

On Tuesday 09 June 2015 15:35:20 Heinz Wiesinger wrote:
> 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. 

Right.

> The release interval is only of minor interest here.

Well, the release interval is for users too, so they can get to the packages 
they want. Developers wouldn't really have to care about it at all if they 
didn't care about who uses what when.

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

That's fine, but development intervals and release intervals are two separate 
topics. I don't care how many times frameworks gets released, but that 
shouldn't mean my libraries version number (which has nothing to do with a 
release), should be automatically bumped every N months.

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

Sure that's great. I don't think that has much to do with the common release,
but rather with creating a brand, but I'm not even opposing a common release.
All I want is to be able maintain my own version, because that's what is used
for the buildsystem (which is essential for portability), the release planning 
(which would help the quality a lot), and is reflected in the so version 
(which again is useful for co-installability and therefore protability).

By bumping versions and dependencies accross the board all of that is broken.

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

Let us look at windows then, where you can largely ignore version numbers 
because everything comes from a webinstaller. To install what you need you 
simply get the latest and greatest, and then you don't touch anything because 
it will break your stuff. Should you be in the unfortunate position to 
actually require something more recent, you get the latest service pack which 
updates all kinds of libraries, that of course breaks something, and the fix 
to that is updating reverting said service pack. Wouldn't it have been nice if 
I could have only upgraded what I actually needed to be upgraded?

(that just happened to me, hence the example)

Same goes for java, another great example how you can bundle a wealth of 
functionality, and where you end up with applications that only work with that 
exact version of java that you then can never update.

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

IMO this effectively results in lower quality frameworks and therefore does 
the opposite of protecting the brand (for the reasons mentioned above).

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

Yes, it's a bit more complex, but it's necessary/useful complexity (because 
you gain something from it). It's however still perfectly scriptable.

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

Sure, I'm arguing that we are on the wrong end of the "possible 
simplicity"/"necessary complexity" balance. Also having proper dependencies 
does make a lot of things simpler in other areas.

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

Given the right scripting that continues to be possible and if you indeed 
think timestamps is the way to go for your distribution you are perfectly free 
to do just that.

Thanks for the detailed input from a packager perspective =)

Cheers,
Christian