On Fri, 1 Jul 2022 at 00:00, Philip Paeps via tz <tz@iana.org> wrote:
As Tom points out, we actually have a fairly predictable schedule today: bursts of releases around the silly seasons in March and October and one or two releases at other times. I'm not too worried about our release machinery atrophying.
And, even if we go an entire "season" without zone changes, leap second data expires twice-yearly as well whether there's a leap-second or not: Even if there are no zone changes in the Mar/Apr season, we would still need a release around May to incorporate the Jan announcement regarding a possible Jun leap-second. Even if there are no zone changes in the Sep/Oct season, we would still need a release around Nov to incorporate the Jul announcement regarding a possible Dec leap-second. So the point about avoiding atrophy is well-taken, but I don't foresee us dipping below a minimum of two releases a year. And because of the above, I also don't see the need to impose any further arbitrary schedule on releases either.
Unfortunately, the nature of the data we record means we'll always have to make releases on short notice.
Yup, no avoiding that. -- Tim Parenti On Fri, 1 Jul 2022 at 00:22, Paul Eggert via tz <tz@iana.org> wrote:
On 6/30/22 22:13, Tom Lane via tz wrote:
IIUC the reason for bundling them is to cover the case where a new tzdata release requires new tzcode.
Yes, in the old days it was never entirely clear what the relationship was between tzdata1997e and tzcode1997e as the two release numbers came from separate lines of development. Now, it's obvious. Also, using the same version number simplifies tarball generation.
Some of this was discussed here:
https://mm.icann.org/pipermail/tz/2012-September/thread.html#18258