On 25/05/2011, at 2:13 AM, Jason H wrote: I think if we could lock the lib and exe to specific versions (like Windows SxS) we'd be better off. We just need a way to link to specific versions of the Qt libraries. (Though SxS is still problematic, I think it is an improvement)
You technically already have what you need with the current releases. The major part of the version is also part of the library name that applications link to (or should link to!). Under Mac and linux, binaries link to llibQtCore.4.dylib and ibQtCore.so.4 respectively. Under Windows, the major version is made part of the library name itself rather than as part of the extension (ie QtCore4.dll) so you have no choice but to link against a specifc major version. Thus, there is already the mechanism required for an application to link to specific binary compatible levels of Qt. Perhaps part of the problem is that the major part of the Qt version changes very slowly. This in turn means that backwards compatibility has to be maintained for long periods. It's somewhat unfortunate that the Qt business/marketing is linked to the technical aspect of version numbering. From a technical point of view, a version number has some fairly well established conventions that many (most?) mature libraries follow. The major part of the version number is what libraries and executables link against (or should link against!). If you build against the earliest release of a particular major version, it should work with all later releases for the same major version. For example, if I built against Qt 4.0.0, it should work with any 4.x.y version. The problem with Qt is that the major part changes slowly and new features people want are introduced with minor point releases. This leads developers to situations where they have to say their software "requires Qt 4.x or later" i nstead of simply "requires Qt 4". This makes the problem of what to link against much harder, because if you make your application link against, say, version 4.4 instead of just 4, then it won't work with 4.5 or later! This is particularly evident as of around Qt 4.6, which had a number of new things added (the pattern of adding more new things continued with 4.7). So the mechanism is there to link against specific versions, it's just that the way Qt increments its version numbers sometimes works against the developer. Now, from a marketing aspect, Qt has a pattern of keeping its major version the same for long periods. People like to be able to say "Uses Qt4", but in reality, "Qt4" isn't enough any more. Too often, I have to ask "Which version of Qt4?", meaning which minor release, since new features appear only in certain minor releases. This is where marketing "Qt4" becomes at odds with what developers need "Qt4" to mean from a technical point of view. There are different ways to address this. One is to decouple the public "marketing" release version from the underlying "technical" version. Examples of this are where you see things like "Autodesk Maya 2010", which makes no mention of the major version number used by the underlying libraries you would link against (it uses Qt 4.5.3, incidentally). They have the freedom to change or keep the major version as they need to from release to release. This sort of decoupling may appeal to some but may also be unattractive to others. Another option is to simply have more frequent major releases. Anything longer than a year is probably too long for the Qt community (many would argue even that is too long), but anything shorter and you risk making Qt too much of a moving target. I suspect that the compliance costs for things like LSB also get higher the more often you change the major version. So that's a couple of ideas for improvement. I'd be particularly interested in hearing if Nokia is willing to consider changing how it handles major version increments to help address this issue, but let's see what other ideas and opinions people have too. ;) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
