<div dir="ltr"><div dir="ltr" class="gmail_attr"><br class="gmail-Apple-interchange-newline">On Fri, 1 Jul 2022 at 00:00, Philip Paeps via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As Tom points out, we actually have a fairly predictable schedule today:<br>bursts of releases around the silly seasons in March and October and one<br>or two releases at other times.  I'm not too worried about our release<br>machinery atrophying.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Unfortunately, the nature of the data we record means we'll always have<br>to make releases on short notice.</blockquote><div><br></div><div>Yup, no avoiding that.</div><div> </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti<br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Jul 2022 at 00:22, Paul Eggert via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/30/22 22:13, Tom Lane via tz wrote:<br>
> IIUC the reason<br>
> for bundling them is to cover the case where a new tzdata<br>
> release requires new tzcode.<br>
<br>
Yes, in the old days it was never entirely clear what the relationship <br>
was between tzdata1997e and tzcode1997e as the two release numbers came <br>
from separate lines of development. Now, it's obvious. Also, using the <br>
same version number simplifies tarball generation.<br>
<br>
Some of this was discussed here:<br>
<br>
<a href="https://mm.icann.org/pipermail/tz/2012-September/thread.html#18258" rel="noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2012-September/thread.html#18258</a><br>
<br>
</blockquote></div>