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 > > > <chrig...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel