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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
