[Development] Qt Commercial 4.8.0 release delta to LGPL version

[BRM]

> From: David Faure <david.faure at kdab.com>

>To: Craig.Scott at csiro.au 
>Cc: development at qt-project.org 
>Sent: Monday, December 19, 2011 3:40 AM
>Subject: Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
> 
>On Saturday 17 December 2011 09:01:35 Craig.Scott at csiro.au wrote:
>> 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
>
>As I said, this doesn't affect QT_VERSION.
>
>I'm only talking about the string representation of the Qt version.
>
>> 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.
>
>I disagree.
>They will post questions to forums, to consultants, on blog posts, etc. etc.
>

I'd still agree that we should leave the Version number alone.
And suggest two things:

1. Digia could add a secondary QT_COMMERCIAL definition to simply let people know the version they are using is the commercial version.
2. Places that show the Qt Version could use the QT_COMMERCIAL definition to add "Commercial" text or however else they want to show it.

If Digia adds functionality - other than bug fixes - then it should probably be wrapped by #1 as well in case people want to build without it from the commercial source.
It could piggy back on the license selection in configure for simplicity.


$0.02

Ben