[Development] Qt Commercial 4.8.0 release delta to LGPL version
Craig.Scott at csiro.au
Craig.Scott at csiro.au
Fri Dec 16 23:01:35 CET 2011
On 16/12/2011, at 10:37 PM, David Faure wrote:
> On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote:
>> So now there is total of 108 improvements and bug fixes available in Qt
>> Commercial 4.8.0 that are not part of the LGPL release.
>
> While I understand the reasons, I want to state that this is going to make
> support a mess.
>
> Both versions are called 4.8.0, but do not contain the same code.
>
> So when someone says "With Qt-4.8.0 I have the following issue", it will never
> be clear which 4.8.0 this is about, we'll have to educate everyone to say in
> addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version
> number be different, when the code is different, instead? E.g. 4.8.0c. That
> doesn't fit into the numerical QT_VERSION, but at least qmake -query and every
> other location which shows a qt version number (packages, qt creator, etc.)
> would show clearly 4.8.0c instead of 4.8.0.
I'd actually prefer to *not* see fiddling with the version number format. That would just make it harder when creating automated scripts to build things and it can also break code that expects the Qt version number to be in the long established x.y.z form. Consider the common (recommended?) way to test for Qt versions in code:
#if QT_VERSION > 0x040800
// ....
#endif
What should this do for something like 4.8.0c? Better to not confuse things and to leave the version number as it was. In practice, I'd be surprised if there was much confusion caused by Digia supplying a customised 4.8.0 which includes just fixes. If people are using Digia's 4.8.0 version, I suspect they are also likely to report bugs they find to Digia instead of to the general Qt bug tracker anyway.
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
More information about the Development
mailing list