Versioning of Frameworks

[Albert Astals Cid]

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

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.

> 
> Alex
> 
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel