On 9/24/21 7:32 PM, Deborah Goldsmith wrote:
> AFAIK Apple software doesn’t have a problem with length, just the pattern, which currently follows the spec.
Yes, thanks for bringing that up. We should consider that in any version
number variant we might want to use in the near future.
If I read the spec correctly, the pattern Apple uses should be
equivalent to the POSIX extended regular expression '[0-9]{4}z*[a-z]' in
the C locale. Am I right about Apple's pattern?
Also, does Apple software insist that version numbers must be in strict
order? For example, does it require that the version after '2021zz' must
be either '2021zza' or a version Ya where Y is a four-digit year greater
than 2021? or could the next version after '2021zz' be anything matched
by the abovementioned pattern? The spec is silent on this subject.
Might I suggest we consider creating a simply-sortable order that naturally allows for more than 26 releases?
That could be as simple as starting with 2023aa, 2023ab...2023az, 2023ba, 2023bb... 2023bz, 2023ca. etc.
I really hope we never have to cope with more than 676 releases in a year :)
> If you propose changing it, there needs to be a new spec, and a considerable period of time (preferably a year) to adjust to it.
Yes, quite so. Plus, the above details should be nailed down. (And the spec
should be extended so that it clearly allows year numbers greater
than 9999 - even though there should be *plenty* of time before that
particular flexibility is needed....)
I suspect that doing so is likely to be burdensome for very little benefit. I suspect that designing a filename format expected to be stable for longer than 7000 years is futile, whereas there are simplicity benefits in having a fixed year length.
If there's ever a sub-group mailing list set up for this (or however we want to discuss it) I'd be happy to be part of it.
Jon