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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team