On Wed, Apr 29, 2015, at 01:29 PM, Martin Gräßlin wrote: > 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 > > > > 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.
I do get this feed back for i.e. libkolab where portability is a necessity. It makes complete sense that it isn't really something you'd i.e. require for kwin, and thus you can also carry on bumping requirements there if that works better for you. > 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. > There is no math involved, because as I said, complexity for upstream does not increase. 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. Just look at Qt: Qt currently depends on glib2 2.8.3 (http://doc.qt.io/qt-5/linux-requirements.html), and on my fedora system I have 2.38.2. No-one expects Qt to be testing qt with every combination of all libraries existing, just because Qt doesn't depend on glib 2.38.2. I think exactly the same applies to frameworks. > > > > > 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. > I don't think you're incompetent developers at all. As you said, noone is using older versions, and thus you don't notice when it breaks, fair enough. From that you can either come to the conclusion that you want to keep dependencies on a minimum nevertheless, and thus employ CI, or that you don't care and thus always depend on the latest and greatest. I assume for you it's the latter and that completely fine. > > 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. > Well, we do currently give BIC guarantees, which means unless a new feature is used this *has* to work anyways. We already promise that if I use the featureset of library version $X it will work exactly the same in version $X+n (apart from major version bumps). If we don't bump the dependency and use a new feature... well, that's just a bug, and bugs happen. You can assume that I will setup some CI to help me ensure it keeps building with the platforms I'm interested in, but that's then my problem for where I choose to do this work. I'm not asking everyone to keep dependencies on a minimum for all available libraries, I'd just like to do this work for a limited set of libraries where this matters to the kolab usecase. And I'm therefore asking whether these libraries can be managed separately, or whether this is causing problems elsewhere in the ecosystem. > > > > > 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. > This should be catched by an integration test that tests the release of all frameworks (I know we don't necessarily have those). In a release I'd expect to have the latest version of every framework, and not the lowest dependency, thus you'd still get those fixes in a frameworks release. In fact, I'm not proposing to change the releases at all, you'd still get exactly the same libraries together, it's just that the dependencies would allow others to package different compilations (which they obviously have to QA themselves). > 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. I very much understand the problem of limited resources, and hence I'm trying to find a solution where I don't complicate life for everybody else, while we can reach the goals explained. > 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. A "best practice" at least for Tier1/Tier2 frameworks would be a good idea IMO, but if I'm allowed to do that for just the limited set of libraries where it matters for this usecase, then I'm already happy. As Kevin pointed out similar requirements exist elsewhere in the ecosystem, so others might follow, but I don't see any need to force everyone to change. > I think that > such an approach is wrong. If we relax the dependency requirement we need > to ensure that it works. I feel like you're overestimating the guarantees we need to give and the effort involved. And if this is only applied to a limited subset of libraries, that would in turn even get additonal manpower, I don't see how it would be doing any harm. Thanks for your input, Christian _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
