Versioning of Frameworks

[Christian Mollekopf]

On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va 
> escriure:
> > 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, 
> 
> I don't exactly get what is "do this", is it only "not autoupdate the 
> depencency versions to the other frameworks"?
> 
> Is it also not autoincreasing the version number?
> 
> Is it something else?
> 

It's not autoincreasing the version number, and not autobumping the
dependencies.

As a maintainer I'd bump the version and dependencies myself, and the
latest stable
version could be released at any time from i.e. an always releasable
master.

So there would IMO be no additional overhead for other people.

Cheers,
Christian