[Development] Abandoning the container changes

marius.storm-olsen at nokia.com marius.storm-olsen at nokia.com
Wed Jul 18 13:04:11 CEST 2012


On 18/07/2012 02:06, ext joao.abecasis at nokia.com wrote:
> Hey,
>
> I would rather we don't *rush* the container changes in, but get them
> up to snuff in a separate branch, instead. I would also like to
> challenge the assumptions I've seen repeated that probability for
> breakage is low and autotest coverage is high. It isn't and it isn't.
> It is very easy to break less-often used features and corner cases
> that will not get caught by autotests. I don't think this is
> acceptable for fundamentals like QVector and friends.
>
> I think it would be feasible to do a binary-only break somewhere
> around the 5.2 timeframe (say, ~12 months) where we address this.
> Technically, this would be Qt 6, but user porting effort would be
> reduced to a recompile. The value of having a long lived (5 years?)
> binary compatible 5.x series is (IMO) low as there are quite often
> other reasons to recompile the stack.

If there's reasons to break BC, there's reasons for a new Major version. 
We don't circumvent the policies because is looks silly to have a new 
major version in such a short time after 5.0.

However, I can imagine there's other significant changes we'll notice 
after 5.0 which will warrant other BC-incompatible changes, and maybe 
we'd want to refactor out more of the modules from QtBase into their own 
repos? As such, we might have several valid reason for having another 
major, to "quickly" correct learned lessons from Qt 5, and to ensure Qt 
6 can live on for a very long time.

Still, if Qt 6 would be on the road-map then, we should aim for making 
transitioning as simple as a pure recompile. We don't _have_ to do 
significant restructuring just because we're going a new major. Simply 
saying that we need to do it because of BC issues is fine. If major 
speed improvements is a result of that, I'm sure many people would 
understand.

Anyways, several people and Thiago himself has said that now is not the 
time for such a change to our tools classes, and we should listen to 
that. I don't think you want to add them both and let the end user 
decide, as it will create a maintenance nightmare, and you will have 
applications which both use Qt 5 but are incompatible with each others 
run-time. (Some apps will demand that you use the "optimized" Qt5 for 
plug-ins etc.)

-- 
.marius

> Cheers,
> João
>
> ________________________________________
> From: development-bounces+joao.abecasis=nokia.com at qt-project.org [development-bounces+joao.abecasis=nokia.com at qt-project.org] on behalf of ext André Pönitz [andre.poenitz at mathematik.tu-chemnitz.de]
> Sent: 17 July 2012 23:59
> To: development at qt-project.org
> Subject: Re: [Development] Abandoning the container changes
>
> On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote:
>> On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote:
>>> On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz
>>> wrote:
>>>> On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira
>>>> wrote:
>>>>> I think that, despite the potential benefits of the changes,
>>>>> we should not apply them at this time. There are far too many
>>>>> chances for breakage and it's a blatant disrespect for the
>>>>> feature freeze.
>>>>
>>>> I assume this is meant as a verdict, not as (possibly
>>>> temporary) state of thinking.
>>>
>>> Correct. The changes are the right thing to do, just not now.
>>> We'll have to live with the current containers and their overhead
>>> until Qt 6.
>>>
>>> That includes the fact that QList<QVariant> is extremely
>>> inefficient.
>>
>> this is absurd.
>
> Incidentally, I agree. [Even if I lack the skill to express myself
> so clearly at times ;-}]
>
>> we said A, now we need to say B. or "unsay" A, which i don't think
>> anyone wants.
>>
>> i for one don't believe in qt6 anytime soon. it's the do-never release
>> qt5 was for years.
>
> The suggested "4 years" are 3 1/2 years too much anyway.
>
> That's 3 1/2 years more of forcing people to re-invent the wheel when
> it comes to performance-sensitive components in a Qt environment, and
> it's 3 1/2 years on top of the past half decade or so where Qt containers
> fail to deliver on one of the original reasons to have them at all
> (portability, convenience of use, _and_ performance).
>
> We do have the chance to fix it _now_, and we have a fairly decent
> idea of how the fix looks like. The whole change is essentially
> source compatible, i.e. has a low probability of breaking other
> components, and it is very well covered by autotests. The chances
> to be ready before the rest (Webkit Windows? Mac?) is ready for
> a 5.0 release are good.
>
> To get back on the constructive side I propose to do any of the
> following, in decreasing order of desirability:
>
> (A) Have the QString/QByteArray related bits in 5.0.
>
> (B) Have everything in 5.0.
>
> (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1
> next.
>
> (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple
> but binary incompatible.
>
> (E) Don't do anything for 5.0, and provide a compile-time switch
> for 5.1 to select between "current" and "patched" versions, default
> to "current". [This is probably the most expensive solution, but
> the one that fits best to "the rules"]
>
> Andre'


More information about the Development mailing list