On Tuesday, 18 August 2026 00:54:22 Pacific Daylight Time Ulf Hermann via Development wrote: > >> In addition, we need per-version profiles. People will want to say "I > >> need to be compatible with Qt 6.14, but I want to adopt all best > >> practices up to that". > > > > Sounds like a distinction without a difference. What are you thinking of > > here? > We may declare now that it's best to avoid AutoText and codify that in > some opt-in mechanism. Users will write code against that and develop > their application with, say Qt 6.14. After 6.14 is released, we'll > figure out that we should also get rid of Qt::Foozle and invoke the same > mechanism for this. Then the person with their application built on 6.14 > will still want to avoid AutoText, but the application will still rely > on Qt::Foozle's old behavior and it will take a while to change that. > They'll want our behavior-breaking changes "up to" Qt 6.14, but no newer > ones. Only if we allow such a thing they can update to Qt 6.15 in a > timely fashion.
That's why we have per-feature defines you can choose from (QT_NO_QPAIR, QT_NO_CONTEXTLESS_CONNECT, QT_NO_FOREACH, QT_NO_KEYWORDS). That's what I was proposing. If you want to adopt "best known practice as of 6.14", you get to adopt it wholesale. But each and every practice should be individually controllable. I'm not a fan of this technique, especially because people tend to think of the *application* choice, when it's really a per-TU choice. The application's choice does not translate to third-party libraries or plugins it loads. I personally don't look at those options. Do we even have them? I just ignore those changes because I believe they are a flawed design. If anyone asked my opinion on any such change, they'll get a -1. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
