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. 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 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. 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)). Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
