On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: > 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.
How can the developer write in KIO's CMakeLists.txt "this depends on KXmlGui 5.5 and KCoreAddons 5.2" without testing that it actually works with these versions? Or the other way around -- if it is at one point indeed working with these versions, what will happen is that someone will use a new feature from an underlying framework at some point, and forget to upgrade the required version. This will happen many times per month, not just once a year, I know this for sure. See the number of times where someone commits Qt-5.4-only code right now in frameworks that are supposed to work with Qt 5.2, but they don't realize when writing QSignalSpy(obj, &Class::member) that this syntax wasn't available in Qt 5.2. It's already a fight to get this right with the *one* Qt version number, I can't even imagine how tricky this would become with 62 * 5 = 310 version numbers to keep right (62 frameworks each depending on an average of 5 other frameworks - I made up that number, feel free to calculate it more precisely). Anyhow, there is little point in arguing for ever about this. As long as I'm doing the Frameworks releases, they will have the same version numbers and they will require the same version number from their dependent frameworks. Sorry to put it so bluntly, but there is no other solution that is actually manageable. Releasing framework is already not a fun task, I will gladly give it over to someone else if they think they can do a better job, but OTOH I think the current release process works quite well (changelog aside), so I would not advocate this (changing it by having someone else do it differently). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
