Hi Jani, > 3 exception requests so far: > - C++20 comparison: exception request accepted > - container-assign epic: exception request rejected
I think it's the other way around - the container-assign epic is accepted, and the C++20 comparison is rejected. Best regards, Ivan ------------------------------------ Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io<mailto:ivan.solo...@qt.io> www.qt.io<https://www.qt.io> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Jani Heikkinen via Development <developm...@qt-project.org> Sent: Wednesday, June 7, 2023 7:20 AM To: releasing@qt-project.org <releasing@qt-project.org>; developm...@qt-project.org <developm...@qt-project.org> Subject: [Development] Meeting minutes from Qt Release Team meeting 06.06.2023 Qt 6.5 status * Qt 6.5.2 preparations started * First internal snapshot created and tested * Target is to branch from ‘6.5’ to ‘6.5.2’ Wed 14th June * Target is to release Qt 6.5.2 Wed 28th June Qt 6.6 status * Qt 6.6 Feature Freeze in effect now & branching from ‘dev’ to ‘6.6’ done * 3 exception requests so far: * C++20 comparison: exception request accepted * container-assign epic: exception request rejected * QMultiMap/Hash support in Qvariant: exception request rejected * API change review started * Most of diffs already available, see https://bugreports.qt.io/browse/QTBUG-114214 * Official review call will be sent to dev ML later this week * Target is to release Qt 6.6 Beta1 immediately after dependency update round succeed in ‘6.6’ Next meeting Tue 13th June 16:00 CET br, Jani Heikkinen Release Manager irc log below [17:00:13] <+jaheikki3> ablasche: akseli: carewolf_home: lars_:mapaaso: The-Compiler:thiago:vohi: ping [17:00:23] <akseli> jaheikki3: pong [17:00:24] <carewolf_home> pong [17:00:26] <vohi> pong [17:00:35] <frkleint> pong [17:00:37] <thiago> jaheikki3: pong [17:01:17] <+jaheikki3> time to start qt release team meeting [17:01:23] <+jaheikki3> on agenda today: [17:01:29] <+jaheikki3> Qt 6.5 status [17:01:33] <+jaheikki3> Qt 6.6 status [17:01:42] <+jaheikki3> Any additional item to the agenda? [17:01:57] <vohi> Lets discuss the requested exceptions from Qt 6.6 feature freeze [17:02:54] <vohi> (as part of the Qt 6.6 status) [17:03:06] <+jaheikki3> vohi: Yes, agree [17:03:19] <+jaheikki3> But let's start from Qt 6.5 status [17:03:36] <+jaheikki3> Qt 6.5.2 preparations started [17:03:54] <+jaheikki3> First snapshot created and tested [17:04:13] <+jaheikki3> Target is to release Qt 6.5.2 Wed 28th June [17:04:36] <+jaheikki3> So branching from '6.5' to '6.5.2' will happen Wed 14th June [17:05:00] <+jaheikki3> that's all about Qt 6.5 status. Any comments or questions? [17:06:27] <thiago> none [17:06:48] <+jaheikki3> Ok, then Qt 6.6 status [17:07:02] <+jaheikki3> Qt 6.6 Feature Freeze is in effect now [17:07:13] <+jaheikki3> 3 Exception requests so far: [17:07:33] <+jaheikki3> C++20 comparison, container-assign epic & QMultiMap/Hash support in Qvariant [17:07:42] <+jaheikki3> vohi: [17:08:01] <vohi> container-assign seems pretty clear cut. [17:08:07] <thiago> greed [17:08:09] <thiago> agreed [17:09:28] <vohi> THe C++20 comparison less so, obviously. The discussion with Ivan has confirmed that this isn't needed for Qt 6.6, and given that the header review process has started, I don't quite see why we need to make an exception here. I respect that a lot of thought and work has gone into the implementation of course. [17:11:21] <vohi> Since we won't make C++20 a requirement for Qt 6.6, and generally don't plan to make C++20 support on any level a part of the launch communication, I'm not quite seeing why we need to make an exception. The scope of what has been done is small, and I somewhat share Thiago's concern that maybe it's too small for us to see all the corner cases. [17:13:14] <+jaheikki3> I understand and agree; we shouldn't make an exception for this because it isn't needed nesessarily for Qt 6.6 [17:14:03] <+jaheikki3> Any objections? [17:14:27] <carewolf_home> no [17:14:32] <vohi> Alex is right in saying that we don't need to roll this out across all relevant types in all submodules, but a bit more than the two or three cases in Qt Core alone wouldn't hurt. [17:15:36] <thiago> I think we need as a validation that it works [17:15:53] <thiago> he has 5 types currently (the 4 date/time types and qfloat16) [17:17:26] <+jaheikki3> It seems we agree no exception for the C++20 comparison [17:17:44] <+jaheikki3> vohi: what about the last one (QMultiMap/Hash support in Qvariant)? [17:18:17] <carewolf_home> is there a timeframe mentioned? [17:19:20] <vohi> no; Peppe doesn't know how to continue based on Thiago's input, so it's a bit open [17:20:11] <vohi> We changed behavior, unintentionally perhaps, from Qt 5 to Qt 6 by making QMultiMap no longer a QMap subclass (ditto QHash) [17:20:56] <vohi> but since no API in Qt uses QVariantMap/Hash as a multi-map/hash, it's gone unnoticed. At least I assume that Peppe's motivation to bring them back is the respective question on inter...@qt-project.org<mailto:inter...@qt-project.org> [17:21:16] <vohi> (https://lists.qt-project.org/pipermail/interest/2023-April/039055.html [17:21:52] <carewolf_home> with out a plan I would lean towards no, it has been broken for a long time so 6.6 vs 6.7 doesn't make much difference [17:22:26] <vohi> we should perhaps establish first that we need those types to be built-in types in Qt at all; we don't use them in Qt ourselves [17:23:16] <thiago> I don't think it makes a difference if it gets fixed in 6.6 or 6.7 [17:23:23] <thiago> it's been 3+ years since 6.0 anyway [17:23:27] <carewolf_home> they not used when converting json objects to qtdeclarative types? [17:23:44] <+jaheikki3> I agree with carewolf_home and thiago: there shouldn't be that hurry with this and on the other hand there is still issues to be solved [17:23:54] <thiago> carewolf_home: not the multi types, no [17:25:07] <carewolf_home> right, no use as multi maps [17:25:23] <thiago> I don't even remember what the issues I had with the patch were [17:25:55] <+jaheikki3> It seems no exception for QMultiMap/Hash support in Qvariant either [17:26:27] <+jaheikki3> vohi: do you know any other exception requests or was these 3 all so far? [17:26:48] <vohi> those are the three I have seen, nothing out-of-band has reached my inbox [17:27:12] <+jaheikki3> ok, then all request have handled now [17:27:18] <vohi> and agree with leaving the MultiHash/Map for Qt 6.7, but would be good if @thiago could give Peppe some assistance [17:28:19] <vohi> as for process: let's review any exception requests in this meeting once a week [17:28:45] <+jaheikki3> Yeah, ok for me [17:28:52] <frkleint> vohi: Have you had a look at QtGraphs? Are we happy with that (it being based on QuickWidget, data APIs) [17:29:14] <thiago> will do [17:30:05] <vohi> @frkleint: it's not been a priority for me, given that it's going out as tech preview at this point; I hopefully get to it next week when I have some face-to-face time with the team working on it [17:30:23] <frkleint> Aha, cool thanks. Good to hear [17:31:11] <+jaheikki3> Ok, back to 6.6 status [17:31:50] <+jaheikki3> Like vohi already wrote api change review process is already ongoing, see https://bugreports.qt.io/browse/QTBUG-114214 [17:32:18] <+jaheikki3> Official review call will be sent to dev ML later this week after I managed to add missing QML ones as well [17:33:08] <+jaheikki3> Dependency update round in '6.6' is also ongoing and the target is to release Qt 6.6 Beta1 immediately after it succeed [17:33:33] <+jaheikki3> That's all about Qt 6.6 status at this time. Any comments or questions? [17:35:58] <+jaheikki3> It was all at this time so let's end this meeting now and have new one tue 13th June at this same time [17:36:08] <+jaheikki3> Thanks for your participation, bye! [17:36:21] <vohi> bye! [17:36:41] <frkleint> bye [17:36:42] <thiago> bye
_______________________________________________ Releasing mailing list Releasing@qt-project.org https://lists.qt-project.org/listinfo/releasing
