Lars Knoll (23 August 2023 13:32) wrote > We have been adding new enum values in certain cases. The operating > system versions needing to be amended to support a new version of > macOS is one example. That has happened a couple of times within LTS > releases as far as I remember. > > We’ve also once or twice upgraded CLDR or Unicode versions within > patch level releases to fix serious bugs, and I believe have in that > process also added new enum values.
On 23 Aug 2023, at 11:48, Edward Welbourne wrote: >> I agree with Marc that we should, at the very least, be clearer about >> what exactly our policy is - and stick to it, > I agree with that, but would propose to amend our policy and > explicitly allow adding enum values in those limited cases. Updates to > Unicode data, supporting new OS versions and maybe a few other limited > cases come to my mind here. Sounds like an update to QUIP 6, or possibly a new QUIP superseding it. https://contribute.qt-project.org/quips/6 So we have * QOperatingSystemVersion Not an enum; { OSType, int, int, int } tuple, with a mass of constants of this type to behave a bit like an enum. Adds one such constant for each newly supported OS version. * QChar (UCD) enums: - UnicodeVersion -- updates whenever we upgrade - Script -- also tangles with HarfBuzz's enum hb_script_t Those both routinely update. In principle, any of CombiningClass, JoiningType, Decomposition, Direction, Category may get new members in a new Unicode release, too. * QLocale (CLDR) enums: - Language, Script, Territory (Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.) In searching for the HarfBuzz tie-in to QChar (which I remember from doing some UCD updates) I didn't find anything in QFont's public API that was obviously affected, but that may just reveal the depth of my ignorance of fonts. I inevitably wonder whether anyone else involved in 3rdparty updates has other examples where an external update extends enums (or other families of names) in our public APIs. Please speak up if you know of any. The other question that arises is: do we try to formulate some generalised characterisation of the circumstances under which this policy applies - public API exposing details of third-party reality - or do we simply document a list of cases where exceptions are permitted ? In the latter case, each extension would require a QUIP update; which conservatively may be considered good, but may be found tiresome in practice. A general rule would allow Maintainers to exercise judgement, possibly in conference with their peers. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
