> From: David Faure <[email protected]> >To: [email protected] >Cc: [email protected] >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 [email protected] 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
