[tz] Commentary-only releases - let's not (was: Re: Please Don't Feed the Trolls (was Kyiv not Kiev))

Tom Lane tgl at sss.pgh.pa.us
Fri Jul 1 03:13:20 UTC 2022

[ disclaimer: I too am just a downstream maintainer ]

Stuart Bishop via tz <tz at iana.org> writes:
> If anything, infrequent releases are more of a problem for me (of course I
> can't speak for other downstreams). The longer between releases, the more
> likely it is that my release machinery has atrophied, the more accumulated
> bugs need to be fixed, and under higher time pressure as the release is
> more likely to have some time critical change included. While I don't think
> every change prompting a release would be good, I do think an expected
> release cadence of one release every 3-4 months would be an improvement,
> along with the occasional unexpected release containing time critical
> changes.

You make some good points, but really that doesn't seem very much
different from the historical state of affairs.  In my recollection,
there is pretty much always at least one release every spring and
every fall, when some-government-or-other decides they need to
change their DST rules with minimal notice.  So in practice there's
a six-months-or-less release cadence, and I doubt that making it
three or four months would change anything noticeable.

The current situation with Kyiv/Kiev is a bit unfortunate in that
the decision to change that name was made just after the March
silly season, so that it will have the maximum probable wait time
before hitting the streets.  Still, I agree with the position that
making a release just for that would be a bad precedent.

What I think might be worth thinking about is decoupling the
tzcode and tzdata release calendars.  The forcing functions for
those two things are *completely* different, and so are the
considerations for downstream maintainers.  IIUC the reason
for bundling them is to cover the case where a new tzdata
release requires new tzcode.  But in practice, there's always
been very strong concern for backwards compatibility, so that
tzdata releases are expected to work with older tzcode; and
I think that has to be so because a maintainer of a tzdata
distribution can't really guarantee that no older code will
be reading that copy of the database.  So I'd be in favor
of a more formal separation.

			regards, tom lane

More information about the tz mailing list