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. It's just, if we don't reflect those changes using version numbers, because all the numbers are always the latest and greatest, then we don't know in what state we are (which library depends on which version of another library etc.). I don't think it eliminates any actual problems though (we're only messing with version numbers after all). As for combinations, I think it's only normal for upstream to only maintain the latest and greatest, and do QA for that only. The regular snapshots that are currently happening can and should continue to happen, and that's a set that can then be QA'd etc. If we did just that, we'd have more meaningful version numbers, and IMO really wouldn't loose anything. I of course would then hope to do some release management on the libraries where it is important enough, and where we can afford to spend the time for that. On the example of kimap that would mean that master would be in an always releasable state, so the frameworks release-process can take snapshots whenever it likes, and other libraries can depend on whatever version is currently in master (knowing that the dependency will be released together with the rest of the frameworks on the next release date). If I don't manage to get the planned features in for the next release, I would simply not merge to master, and the framework would stay the same. If anything that would reduce the combinations that have to be tested, because some will just stay the same. > Also we're doing it similarly to how Qt does it anyway. Is it also a > problem to bump all Qt frameworks when you need another one? Is there > something that comes easier there that we don't offer? Or is it that > we just have too many frameworks? Hmm... Didn't think about that a lot so far.I think in general it would be valuable for Qt too treat individual libraries separately. I think it's less of a problem in that case, because the possibility that we have to update Qt is much lower (I'd typically rather workaround a problem instead of distributing a patched Qt version, which I guess is a symptom of the same problem). So Qt is largely not update-able in my world, which is why I also currently have to maintain compatibility back to Qt 4.6.2. This of course comes at the cost of maintaining workarounds, and at an opportunity cost that I end up working workarounds instead of the core product (Qt). I don't think we have too many frameworks, what's important for us is to keep the dependencies to a minimum, and to keep the necessary changes is those dependencies to a minimum. If we find a bug in version 1.6.3 of library X (and it really shouldn't matter whether it's a KDE framework or some other library), then we patch it if feasible and distribute a fix. If we did our job with that fix we're not breaking any other uses of that library on the same system an thus we're good. If we rely on a new feature of the same library that is in version 1.9, and we see that all dependencies are still the same, then we can update to this new version with relatively great confidence and ease, because we're not touching a whole lot. If updating to 1.9 pulls in a whole tree of required updates it's just unlikely to happen, and I end up implementing some obscure workaround for that. So I don't think Qt offers anything that helps the problem, it's just that we interact less with it, and often we just use what's there since forever anyways and thus we don't care a whole lot about versions. Cheer, Christian _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
