> 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
