Versioning of Frameworks

[Christian Mollekopf]

On Sun, May 10, 2015, at 03:39 PM, 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.
> 

I completely understand that. I'm searching for a solution that works
for everyone, and I'm pointing out that the current situation does not
work for me (as a maintainer of kimap that should become a framework, as
a KDE PIM developer and as kolab developer).
I only wanted to elaborate on why I can deal with the Qt situation,
but can't really with the one in frameworks.

> > So for me each framework is an individual library, and
> > should be treated as such,
> > because I do want to work on the respective framework instead of running
> > in my own circles in wherever I use the framework.
> > I therefore need to be able to use the results of that work on all my
> > target platforms, otherwise working
> > on the framework is just having me implement the same thing twice.
> 
> Making it possible for people to work on frameworks and then use the
> result in their applications quickly is exactly the reason why we have a monthly
> release cycle (unlike Qt). 

I'm trying to point out that this solution does not work for the
scenario I want to use certain (soon to be) frameworks, which is
deployed on a server in an enterprise environment. In these scenarios I
can't just tell to run the proverbial "yum update" to pull in as many
packages as I like. Either I manage to keep changes to a justifiable
minimum that we can be tested sufficiently, or I have to implement a
workaround. And implementing workarounds to use the real fixes a year
later once we actually get to upgrade all systems to the required
frameworks version is not a sustainable solution.

> You can implement stuff in KF5 and use it the month
> that follows in the layers above. 

In an enterprise environment I simply can't. This works very well for
the developer on his bleeding edge machine, but in other cases just
doesn't.

> This is orthogonal to the discussion on version 
> numbering, i.e. I definitely don't see this as an argument in favour of 
> version hell.

There are numerous reasons for me to advocate individual version numbers
per library that are controlled by the maintainer, but I don't see the
discussions as orthogonal:
* I need the version number as a tool as maintainer to do some release
engineering.
* Bumping version numbers and dependencies periodically doesn't work for
the enterprise usecase (due to random changes getting pulled in for an
otherwise trivial update).
* By removing the version number we remove a valuable communication tool
from the individual libraries.

I appreciate all the work you're doing, and I'm certainly not trying to
make your life or anyone elses harder, but these are actual problems I'm
facing that I need to solve somehow, and that I think are solvable. But
it would help to get some more input on what the actual problems on your
end are other than some references to "version hell". If we can solve
the problems I'm also perfectly willing to do the work that is
necessary.

Cheers,
Christian