[lsb-discuss] Modularization design proposal
audiofanatic at gmail.com
Tue Apr 3 23:11:37 UTC 2012
On 04/04/2012, at 8:26 AM, Robert Schweikert <rjschwei at suse.com> wrote:
> On 03/30/2012 06:12 PM, Wichmann, Mats D wrote:
>> On Fri, Mar 30, 2012 at 4:08 PM, Craig Scott <audiofanatic at gmail.com
>> <mailto:audiofanatic at gmail.com>> wrote:
>> Just wondering how the Qt modularisation would work. Would it
>> include Qt3 and Qt4? With Qt5 about to come out, Qt3 will shortly be
>> end-of-lifed (many would argue it already has been). There has been
>> a long time with Qt3 being deprecated, so it could be argued that
>> Qt3 is just about ripe for removal from the LSB for the LSB 5.0 release.
>> it's almost certain qt3 will be dropped for 5.0, but your question is
>> still an interesting one, as we would have to think about does a qt
>> module mandate two qt versions at the same time when qt5 does become a
>> candidate - which is probably not for 5.0
> Basically I agree with Mats, QT3 will be gone for 5.0 and Qt5 will not be a candidate for 5.0. But I'd like to take this a bit father. IMHO we should not have 2 versions of the same toolkit "active" at the same time. Meaning when we add Qt5 we should deprecate Qt4. The result is that the LSB-Toolkit-Qt module always points to the latest version and there will be a version LSB-Toolkit-QtX where X stands in for the version of the deprecated toolkit.
But in this case qt4 and qt5 have some fairly fundamental differences. Yes qt5 is supposed to be source compatible with qt4, but the structure of the libraries etc will be very different. There is also a fundamental shift in functionality and focus on mobile form factors for qt5, one side effect of which will potentially be a significant number of people remaining with qt4 for quite some time. It is also likely that the early qt5 releases will have a few rocky areas (that's my assessment anyway) since there will be a significant amount of stuff that wasn't in qt4 (eg the qml stuff has been overhauled significantly).
I'd recommend not moving qt4 to deprecated until qt5 had been out for at least 1-2 years in most mainstream distros (the community ones at least).
Your suggestion of including the qt version number is interesting. I'd actually take it one step further and include the version numbe not just for the deprecated version, but for the current version in the lsb as well. That is clearer and would also mean nothing would break in the dependencies devs use when a module is switched over to being deprecated.
> Yes, this means people that insist on sticking to things we deprecate have to change their dependency checking code.
There's not need to if we include the versions as suggested above. As a developer, I'd much prefer that.
More information about the lsb-discuss