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

True, but that does somewhat go against the original spirit of
frameworks.
It's of course an option, but not the most desirable one IMO.

Also, it creates unnecessary friction because some people will want to
move libraries
to frameworks while others don't... Really something I'd rather avoid.

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

Yes, I've done plenty of backporting. Again, something we can do, but
keeps me
running in my own circles instead of doing the work upstream.

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

If version numbers are bumped across the board I end up maintaining
stable versions
for the complete dependency stack. Again something I can do, but instead
of working on
the most recent version I put my time into developing for ancient
versions.

Your suggestions of course work, and is what we're doing with the
pre-frameworks libraries as well.
It just IMO steers the resources in completely the wrong direction
because I end up working on stuff
that noone profits directly from and puts an unnecessary burden on me as
a maintainer of a potential framework,
which makes frameworks for me unnecessarily unattractive.

Cheers,
Christian