Date: Wed, 22 Sep 2021 11:30:38 -0700 From: Paul Eggert via tz <tz@iana.org> Message-ID: <2184234f-a2f3-7bbe-a9da-db21bbac7c71@cs.ucla.edu> | * We release 2021b pretty much as-is | | * We also generate a separate 2021a1 version, | I'll do this by publishing a patch to 2021a, along with a patched | tarball, on my website at UCLA. | | Although this is effectively a fork in the short term, It is, but it is a trivial one, as no-one is even going to notice the oddly named version on a UCLA server - so what you're suggesting is to more or less presume that the "as-is" (which means, as-isn't really as that version has never been released) becomes that new version, and you're totally ignoring all the "revert to 2021a for now" requests from just about everyone. | There is precedent for this approach, in that when there were | compatibility problems with earlier releases, I generated alternate | tarballs to support downstream users while they were adapting their | database readers. Although the two cases are not the same, generating an | alternate distribution also has the benefit of giving us time. They're not even close to the same - that way provided two different methods to arrive at essentially the same output data, one for people with sane up to date parsers, and one for those lagging behind. That was fine, and apart from the slight amount of extra (self-imposed) work for those with parsers that didn't parse correctly (and your extra effort in generating support for them) that harmed nothing. | Since Samoa's rules change in less than 72 hours I plan to generate | these new versions soon. Don't. Just generate the thing you were going to call 2021a1, call it 2021b, and distribute it the normal way. If there is any justification at all for the other changes (which I fail to see - it certainly is not that bizarre discrimination argument) then that can be considered before 2021c (or more likely some 2022 version) - I certainly cannot see any urgency in any of those changes, even if they had some merit. kre