Future frameworks releases

[Christian Mollekopf]

On Tuesday 09 June 2015 11:16:17 Raymond Wooninck wrote:
> On Tuesday 09 June 2015 10:50:36 Christian Mollekopf wrote:
> > > Biggest problem here, at least for now as i can see, are dependency
> > > versions for those with their own scheme.
> > > Now we can have
> > > (build)requires >= %version
> > > but with the new setup we would need to check each individual
> > > framework for raised versions.
> > 
> > As far as I am concerned dependencies are there to express the
> > requirements
> > of a piece of software, and for portability and stability the lower the
> > better (which is not to say dependencies shouldn't be bumped, but they
> > should be bumped for a reason). By going "(build)requires >= %version" you
> > create one giant monolithic blob, which is not a good idea at all IMO. So
> > yes you can no longer do that, but it's also only marginally better than
> > ignoring the version alltogether IMO.
> 

Hey Raymond,

> Christian,  See it from a distribution point of view. If we update to KDE
> Frameworks 5.12 (as an example), then we want to have the situation where
> the user would end up with all the correct libraries and not in the
> situation where one framework library is version 5.12 and an another one is
> version 5.10, etc.
> 

You want to end up with all dependencies satisfied, it doesn't matter what 
version they are.

> Yes, for building the frameworks, the version checks in the CMakeLists.txt
> files could be sufficient if properly maintained. However it would also
> depend on the buildsystem is used by the distribution. Otherwise one could
> end up that a  Tier3 library is build against an older version of a tier1
> library and afterwards the tier 1 library is updated to a higher version.
> 

A common problem I assume given that most libraries out there have their own 
version number?

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

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

All that said, if a distribution decides that it is indeed a good idea to 
timestamp all the libraries then it's perfectly free to do so. Grab the 
tarballs, assign whatever version you want to and release them as such.
Then at least others can decide differently if they want to.

Cheers,
Christian