Versioning of Frameworks

[Christian Mollekopf]

On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
> On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> > On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> > > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> > > <chrigi_1 at fastmail.fm> wrote:
> > > 
> > > 
> > > Hi Christian,
> > > I understand your needs, I've seen similar complaints before.
> > > 
> > > Letting frameworks depend on different versions could make sense, but
> > > I also fear it might make it much more complex to maintain quality as
> > > a whole. For example, in Plasma we've had problems already because of
> > > the fact that we need to make sure different versions are compatible
> > > with each other. Also we won't be able to run our CI with every single
> > > combination, which also makes it slightly more complex.
> > 
> > I understand why it may seem more complex, but I don't think it actually
> > is.
> > Whether we choose to track development process using a version number,
> > or whether we choose to track time using that number, what happens in
> > the code
> > remains the same. The same goes for dependencies; We will always have to
> > rely on
> > newer features sometimes, and thus bump dependencies.
> 
> which means it will in practice be always broken. Real world example:
> kwin.git/CMakeLists.txt
> 
> set(KF5_MIN_VERSION "5.8.0")
> 
> yeah sure, that looks a lot like someone forgot to update the dependency.

I don't think the claim that because it can break, it's in practice
always broken, holds.
Of course it's possible that it breaks, and typically this results in
someone complaining (ideally CI),
which gives you as developer two options:
* Don't use the feature because you didn't mean to bump the dependency.
* Bump the dependency

This is IMO valuable feedback.

> We 
> basically require that developers check for each change:
> * which version of a given framework the API call was introduced
> * whether that's currently the required dep
> * otherwise increase the dep
> 

Yes, that is something necessary that everyone does for all other
libraries as well.
When your required library is not available on the target platform you
won't have any fun developing for it.
If for kwin you always rely on the latest feature from library X, then
you're certainly entitled to bump that dependency
for every release. Keeping dependencies low is mostly interesting for
lower-level libraries that strife for portability and thus
try to keep dependencies to a minimum. I'm not interested at all forcing
that focus on anyone,
just in enabling those who have it anyways.

> That's not going to work. We either have CI for that (which we don't and
> don't 
> have the resources for) or we go the secure rout: bump all at once.
> 

Bumping cmake dependency version does not give any security IMO.
Frameworks can continue to provide snapshots of the latest and greatest
that
have been QA'd etc. I see absolutely no need to give any guarantees
beyond that,
and if for kolab we use some exotic combination of versions on some
obscure platform,
then it is indeed our responsibility to ensure that this actually works
by i.e. running appropriate CI.

> As much as I think that in theory you are right and a more fine
> granulated 
> dependency checking would be better, I doubt that this can work in
> practice 
> without proper CI (and of course the CI can only check build deps, not
> runtime 
> behavior changes (e.g. KWin needs a bugfix from KWindowSystem 5.10)).
> 

Unittests do check runtime behavior, and while I appreciate that our
world is not perfect
and not everything is completely covered, just bumping versions doesn't
solve
the problem. Btw. I'm not even suggesting changing the combined software
versions:
libkolab depends on Qt 4.6.2 since forever, but I'm certainly not
developing using that ancient version.

Cheers,
Christian