Versioning of Frameworks

Wed Apr 29 11:29:12 UTC 2015

On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote:
> 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.

out from my experience: we don't get this feedback. These are unlikely 
combinations which hardly anyone uses. Distros give you a combined "latest" 
release. This will be the one in a million use-case like yours. So the 
frameworks you use will continue to work, because you will notice. What about 
the others? We have currently > 60 frameworks, with each release introducing 
more. Do the math of the possible combinations.

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

I can give you several examples where KWin increased the required dependency 
without increasing the required version and again with nobody noticing (I just 
checked the CMakeLists.txt - for dependencies like KDecoration2 or KWayland we 
do not even specify a required version). How come this is not caught? Because 
nobody uses these outdated versions. We depend on something distros already 
provide (heck even I use distro packages), thus the fact that we start to 
depend on later versions won't be caught by distros compiling, neither by 
users compiling. My reality shows me that this is not working and I doubt that 
KWin is full of incompetent developers who cannot get the dependencies right.

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

really? I would be pissed as a user if it promises a dependency which it 
doesn't work with. That's kind of an external contract in my point of view.

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

How is a unit test going to ensure that KXmlGui has the bug fix from 
KWindowSystem? We won't add a unit test to KXmlGui for the bug found in 
KWindowSystem. We'll add that test to KWindowSystem. That's the kind of 
runtime dependencies I mean which no unit test can catch.

To me not having the dependencies increased at the same time is providing a 
promise which we cannot with our current architecture and man power hold. 
That's why I think it's a bad idea. From what I understand for you it would be 
good enough that it's a "best practice", it might work or not. I think that 
such an approach is wrong. If we relax the dependency requirement we need to 
ensure that it works.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150429/f685f6c7/attachment.sig>