Versioning of Frameworks

[Christian Mollekopf]

On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va 
> escriure:
> > On Sunday, May 10, 2015 15:39:02 David Faure wrote:
> > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > > > * I'd consider Qt to be a lower level library. Qt mostly provides
> > > > fundamentals just like libc or the STL,
> > > > and it's therefore okay for me to just work with what I have available.
> > > 
> > > I hope you can understand that the decision on how Qt (on one side) and
> > > KDE
> > > Frameworks (on the other side) should be released, does not only depend on
> > > the way *you* consider Qt and KF5. Other people have a different view on
> > > both (e.g. Qt developers do work on Qt, while app developers might treat
> > > KF5 as something "fundamental where they just work with what they have
> > > available). You want to draw a line somewhere, while others draw it
> > > elsewhere, and yet we have to make decisions that work for everyone, not
> > > just for you.
> > 
> > it's not just him.
> > It's me (at work) too. Maybe many developers which use Qt at work (with an
> > commercial license).
> > There I have Qt available, as Christian says, it feels like a system
> > library, our application is built on it.
> > 
> > Now from time to time we need some additional functionality. This is the
> > place where frameworks libraries could come in. The easier this is, the
> > better. Easy would mean that if I need kfoo, and this depends on
> > kcoreaddons and kwidgetaddons, I need to add only those three libs to my
> > build, and when kfoo has a bugfix I need, I don't have to automatically
> > update also kcoreaddons and kwidgetaddons, but only if this is really
> > necessary (i.e. kfoo started using functionality from newer versions).
> > This indeed requires that maintainers carefully maintain which versions of
> > their dependencies are needed (sometimes not requiring the newest version is
> > also a good thing).
> 
> Honestly it is your job as "creator of a product" based on this libraries
> to 
> decide if to upate to the next version with what it entails or to
> cherry-pick 
> the bugfix into your code (as you do with Qt).
> 
> What you're dreaming is a library that does what you want and has no 
> dependencies, because for you the problem is not that updating kfoo may 
> depends on kcoreaddons and kwidgetaddons, it is that has any dependencies
> at 
> all, what if the same release that fixes the bug you need adds a new
> feature 
> that introduces a dependency in liblava? You have the same "problem".
> 

There's always the possibility of such problems, but they can be greatly
reduced.

> Of course I understand that you'd prefer that we did this stabilization
> work 
> instead of you, but you have to understand there's simply not the
> manpower to do this.

I'd like to point out that all that is wanted that I'm allowed to do
this for the libraries
where I do the work, everywhere else you are of course free to do
whatever works for you.
Noone is asking anyone to do this work for all frameworks,  we simply
need the "everything
is the same version" policy removed, so the people who care can do the
work for the frameworks
where they care.

Cheers,
Christian