Versioning of Frameworks

[Albert Astals Cid]

El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va 
escriure:
> 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.

I just want to point the obvious solution of "you don't need to make kimap a 
framework, you can just release it yourself and problem fixed" (not sure if 
anyone had before, it's a long thread :D)

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

In an enterprise environment, you control everything, just cherry-pick the 
fixes you need, since we're assuming here you need exactly the bugfixes you 
want (since you know which versions to update and where, etc)

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

That's nothing to do with "bumping version numbers", and everything to do with 
the lack of a stable version, again as an enterprise, it's your task to 
"productize" the library if the library doesn't do everything you need.

> * 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
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel