On Tuesday, 22 August 2023 14:27:09 PDT Marc Mutz via Development wrote: >>> I think we should decide what we mean by forward BC and SC and >>> describe it in https://wiki.qt.io/Qt-Version-Compatibility more >>> precisely.
On 23.08.23 04:48, Thiago Macieira wrote: >> I thought the rule was "no new symbols, period" with the exception >> for QOperatingSystemVersion for operating systems that have been >> released since that Qt release was made. Marc Mutz (23 August 2023 07:52) replied: > Indeed. This is how I remember it, too (though the exception is new to > me), but that is clearly not what the project is producing atm, > therefore I decided to raise this here. All of which makes perfectly good sense, but we do have history of adding new members to other enums. The example I'm familiar with - that I dimly remember, although one should be wary of trusting my memory and I can't find where it happened, asking Lars about when he was Chief Maintainer, and continuing at his bidding - is adding members to QLocale's Language, Script and (formerly and still technically Country, now to be thought of as) Territory enums. The documentation of these does get "since" annotations (and these will reference future versions, if we don't amend them during or after picking) that could be the basis for "don't use these overtly in code if you care about backwards-and-forwards compatibility" docs (that should be added, if we continue doing this). They only present a problem if the client code overtly exercises the new enum members. To quote (with [minor changes]) the commit message of (trial baloon) https://codereview.qt-project.org/c/qt/qtbase/+/498607 The counter-case is that client code generally only queries the available locales to ask the user to pick one, then uses it; or reads a locale ID from some source (e.g. HTTP headers) and passes it to QLocale to make sense of it. That [may] exercise newly-added enum members, in which case it will be a behavior change between patch releases (we now support locales we did not before), but the same can arise simply from CLDR adding data for locales we already do have the codes for in our enums. In any case, code doing this will run when compiled and run-time linked against different patch releases, in either direction; and users gain the benefit of the new enum members [and locales] if they update their Qt libraries. which I suppose to be the rationale for past post-x.y.0 additions to these enums. This benefit may well be significant for some users and authors of client code do have to go out of their way to break it. I agree with Marc that we should, at the very least, be clearer about what exactly our policy is - and stick to it, Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
