[Development] Requesting Feature Freeze Exception for C++20 comparison

Alex Blasche alexander.blasche at qt.io
Tue Jun 6 08:45:03 CEST 2023


________________________________________
>From: Development <development-bounces at qt-project.org> on behalf of Volker Hilsheimer 

>Lets continue with this for Qt 6.7.

>Even if we agree on the naming and can exclude binary compatibility issues, 
>rolling this out to all (or at least a substantial amount of) existing value types across >submodules is still a larger effort that should then wait for 6.7 anyway.

I don't see it as necessary to roll this out throughout all submodules with such a tight 6.7 schedule. This won't happen for Qt 6.7 because most devs may see this adoption as somewhat optional or at least do it on their own timeline. The point of using date and time as example was to proof the concept. This is an API offer for other maintainers to adopt in their API offering. We have never made it a condition for features to be adopted by every single module. It has always been a multi release affair and by comparison is the same as API deprecation from an adoption perspective.

The patch series was up for review and there was a very active discussion including naming for weeks already. While I accept concerns I am very disappointed that such reviews come in 2 days before FF with immediate rejection for the upcoming release due to timing. This was not the first time. Since this diminish my confidence that this won't happen again I would like to see a measure in place that can avoid this. 

IMO the compat and naming issues can be worked out (FF extension is sufficient). I very much object to delaying because of submodule adoption. It was always out of scope for 6.6 and for 6.7 it is not achievable either. Hence it cannot be a reason for delaying comparisons.

--
Alex


More information about the Development mailing list