[Development] HEADS-UP: Branching from '6.6' to '6.6.2' done
Hi! We have branched '6.6.2' from '6.6'. So from now on all changes targeted to Qt 6.6.2 release must have 'Pick-to: 6.6.2' and '6.6' is for Qt 6.6.3 release. As usual staging in '6.6.2' is restricted to release team only and we will monitor incoming changes and stage the clear ones in automatically. Please do not add any nice-to-haves in '6.6.2' anymore; those can wait Qt 6.6.3. The target is to release Qt 6.6.2 by the end of January 2024. There were few changes integrating in '6.6' when branching was done so please check if those needs to be manually cherry-picked in '6.6.2' or not. br, Jani Heikkinen Release Manager -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Marking the Tech Preview APIs as such
Il 22/01/24 19:03, Shawn Rutledge via Development ha scritto: I guess your goal is to be able to see it in the header rather than having to look up the docs in the cpp file or online? (Alternatively we could write all docs in headers, but then the headers get to be large, take storage space alongside every installation of Qt binaries, and slow down everyone’s compilations, so I guess that’s why we don’t do it that way? Or we could somehow include doc diffs in API review patches for whatever API the script has already decided is “interesting".) As I said, it's not just in order to see the tag in the header when the code is introduced, but also to see that a TP class is getting out of TP status because the tags are being removed (= the header is being touched, and will appear in the header review). If \preliminary is removed from the docs, it won't be obvious at API review time. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Question about the licensing of the Protobuf-Module
This was (sadly) a bug, see comments: https://bugreports.qt.io/browse/QTBUG-117783 Cheers , Eli On 1/22/2024 10:29 AM, Frank Meerkötter wrote: I am looking for a clarification on the licensing of the Protobuf-Module. The code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobuf has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only While the code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobufqttypes/protobufqtcoretypes has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0 Is this intentional? Can I - wearing a LGPL3-hat - use the protobuf module? Thank you, Frank -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Marking the Tech Preview APIs as such
On Jan 22, 2024, at 10:41 AM, Giuseppe D'Angelo via Development wrote: Hi, A number of classes and functions that are going to be introduced in 6.7 are meant to be "tech preview", and thus they may pass the header review even if we are aware of some limitations or issues with their design. I propose to introduce a macro, QT_TECH_PREVIEW_API (bikeshed please), that expands to nothing/`[[qt::tech_preview_api]]`/... (moar bikeshed) and it's used to mark APIs that are considered tech preview. The first goal of this macro is to ensure that making an API officially supported (and out of TP) will require changing the header, and therefore be picked up in the next round of header reviews. Otherwise, there is the chance that an API becomes official by simply adjusting the documentation, and one may not notice that this has happened during the next API review (and confirm that all the shortcomings have been addressed). The second goal would be for qdoc to automatically document methods and classes marked by the macro as TP. We have the qdoc \preliminary tag. But we haven’t always used it consistently; some docs just have a \note instead. https://doc.qt.io/qt-6/16-qdoc-commands-status.html#preliminary If a whole class is considered to be Tech Preview, it’s easier to add one note than to mark every function as preliminary. In the case of the TextDocument API, it was exposed only for C++ API before (as a middleman to provide access to the QTextDocument that a TextEdit is using), and now it’s gaining properties and invokables, so effectively the whole class is Tech Preview from a QML-API perspective. I guess your goal is to be able to see it in the header rather than having to look up the docs in the cpp file or online? (Alternatively we could write all docs in headers, but then the headers get to be large, take storage space alongside every installation of Qt binaries, and slow down everyone’s compilations, so I guess that’s why we don’t do it that way? Or we could somehow include doc diffs in API review patches for whatever API the script has already decided is “interesting".) -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Marking the Tech Preview APIs as such
Hi, A number of classes and functions that are going to be introduced in 6.7 are meant to be "tech preview", and thus they may pass the header review even if we are aware of some limitations or issues with their design. I propose to introduce a macro, QT_TECH_PREVIEW_API (bikeshed please), that expands to nothing/`[[qt::tech_preview_api]]`/... (moar bikeshed) and it's used to mark APIs that are considered tech preview. The first goal of this macro is to ensure that making an API officially supported (and out of TP) will require changing the header, and therefore be picked up in the next round of header reviews. Otherwise, there is the chance that an API becomes official by simply adjusting the documentation, and one may not notice that this has happened during the next API review (and confirm that all the shortcomings have been addressed). The second goal would be for qdoc to automatically document methods and classes marked by the macro as TP. Ideally, this should happen for 6.7 itself, if there's still time. Opinions? -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Question about the licensing of the Protobuf-Module
I am looking for a clarification on the licensing of the Protobuf-Module. The code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobuf has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only While the code in https://code.qt.io/cgit/qt/qtgrpc.git/tree/src/protobufqttypes/protobufqtcoretypes has // SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0 Is this intentional? Can I - wearing a LGPL3-hat - use the protobuf module? Thank you, Frank -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 870 589 - 161 | Fax: -199 frank.meerkoet...@basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
