> On 23 Aug 2023, at 15:09, Edward Welbourne via Development > <development@qt-project.org> wrote: > > 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
As QUIP 6 focuses specifically on SiC changes between minor releases, and since the technicalities that influence what we can do within a patch cycle (in particular our ambition to maintain forward binary compatibility) are somewhat different from that, a separate QUIP might be cleaner. > 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. If we focus such a QUIP exclusively on where we allow what kind of additions within a patch cycle, then I think we should be explicit about each case, and have a good change process for each addition. I can, from the top of my head, not come up with more than what you listed above. Everything else is not allowed. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development