[Development] BC/SC in patch releases (particularly enum additions)

[Volker Hilsheimer]

> On 23 Aug 2023, at 15:09, Edward Welbourne via Development <development at 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