Versioning of Frameworks

[Christian Mollekopf]

On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
> On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
> > You don't have to maintain any other combinations that what you already
> > do.
> > Just because the cmake versions aren't automatically bumped doesn't mean
> > you suddenly have to test every conceivable combination of versions.
> 
> How can the developer write in KIO's CMakeLists.txt "this depends on
> KXmlGui 
> 5.5 and KCoreAddons 5.2" without testing that it actually works with
> these versions?
> 

Because he tested that when he originally added that dependency, and
never changed anything related to that.

> Or the other way around -- if it is at one point indeed working with
> these 
> versions, what will happen is that someone will use a new feature from an 
> underlying framework at some point, and forget to upgrade the required 
> version. This will happen many times per month, not just once a year, I
> know this for sure.

Yes, if somebody introduces a bug we have a bug. If I as a maintainer of
a library decide keep dependencies low
it's my responsibility to keep that working. Personally I'd do that
using CI, by building additionally to a system with the
latest version, in a system that has only the minimum dependencies
installed.

It's additional work, but it IMO yields a higher quality product, and
it's what I'll have to do if I want that library to be used in an
enterprise environment.
 
> See the number of times where someone commits Qt-5.4-only
> code 
> right now in frameworks that are supposed to work with Qt 5.2, but they
> don't 
> realize when writing QSignalSpy(obj, &Class::member) that this syntax
> wasn't 
> available in Qt 5.2. It's already a fight to get this right with the
> *one* Qt 
> version number, I can't even imagine how tricky this would become with 62
> * 5 
> = 310 version numbers to keep right (62 frameworks each depending on an 
> average of 5 other frameworks - I made up that number, feel free to
> calculate 
> it more precisely).
> 

I know it can be tricky, happens to me as well. Simply ignoring the
problem by always bumping all requirements doesn't result in a higher
quality product though. The complexity is not as high as you make it
sound, because the maintainer of the library is the one that also
maintains it's version number (or should be IMO), if there is a lack of
manpower for some libraries to do that they can continue to do what
they've been doing.

> 
> Anyhow, there is little point in arguing for ever about this. As long as
> I'm 
> doing the Frameworks releases, they will have the same version numbers
> and 
> they will require the same version number from their dependent
> frameworks.
> Sorry to put it so bluntly, but there is no other solution that is
> actually 
> manageable. Releasing framework is already not a fun task, I will gladly
> give 
> it over to someone else if they think they can do a better job, but OTOH
> I 
> think the current release process works quite well (changelog aside), so
> I 
> would not advocate this (changing it by having someone else do it 
> differently).

That's unfortunate. I think this is a problem and I do hope we'll find a
solution that works for everyone.
I completely understand that you don't want this already complex task to
be any more complex, but IMO it wouldn't have to be.

Thanks for the detailed responses in any case.

Cheers,
Christian