[Development] buildsystem now needs to keep behaviour compatibility

Knoll Lars Lars.Knoll at theqtcompany.com
Fri Dec 11 08:44:29 CET 2015

On 10/12/15 15:37, "Development on behalf of Koehne Kai" <development-bounces at qt-project.org on behalf of Kai.Koehne at theqtcompany.com> wrote:

>> -----Original Message-----
>> From: Development [mailto:development-bounces at qt-project.org] On
>> Behalf Of Oswald Buddenhagen
>> Sent: Wednesday, December 09, 2015 11:45 AM
>> To: development at qt-project.org
>> Cc: releasing at qt-project.org
>> Subject: Re: [Development] buildsystem now needs to keep behaviour
>> compatibility
>> On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote:
>> > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote:
>> > > We should then keep build tests for these modules in the CI.
>> > > Otherwise we won't notice breakages.
>> >
>> > I agree.
>> >
>> this is true.
>> but that basically defeats the whole point, which was not needing to care
>> about these modules any more.
>> now reality caught up already and it turns out that i broke webkit.
>> well, what i actually did, i broke bug-to-bug compatibility, which exposed a
>> pre-existing problem in webkit, as it usually goes.
>> it would be possible to revert the respective qmake change (and uglify the
>> surrounding code), but i don't think it's reasonable to enforce this type of
>> stagnation - we generally accept that code which relies on undefined or
>> outright broken behavior is broken by fixes.
>> so how do we go from there? i see several options:
>> - continue to drag along webkit and the other deprecated modules. the
>>   additional cost of actually doing that in addition to compatibility
>>   testing is rather low with the new CI.
>I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work...

+1. This is probably the best compromise we can come up with.


>> - release further 5.5.x versions of these modules when necessary. i
>>   expect this to be a lot more effort than the first option, so it
>>   doesn't seem reasonable.
>> - simply accept that it's broken, and tell people to apply patches.
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>Development mailing list
>Development at qt-project.org

More information about the Development mailing list