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

Stuart Bishop stuart at stuartbishop.net
Fri Jul 1 02:45:00 UTC 2022

On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz at iana.org> wrote:

> On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
> > even though usually a new version of the DB is only released if some
> > TZ rule was changed, it should not be too hard to simply release a new
> > version now
> I strongly disagree with this view.
> While the effort required from the tz coordinator to tag a release may
> be minimal, this is not the case for the many downstream maintainers.
> Every update presents a risk.  Bear in mind that tzdb updates end up
> being pushed to hundreds of millions of end-user devices, if not more.
> Downstream maintainers are cranky enough as-is, following the churn in
> 2021 (which still has not been completely resolved).  If we start
> tagging tzdb releases without actual tz changes, downstream maintainers
> will be even more likely to diverge from the closely tracking tzdb.
> This is ultimately bad news for end users.
> For the avoidance of doubt: I completely agree that renaming Europe/Kiev
> to Europe/Kyiv was the correct thing to do.  My objection is to tagging
> tzdb releases with only commentary changes and no data changes.

Counterpoint, as a downstream maintainer I would appreciate prompt releases
for popular requests such as the renaming of Europe/Kiev. Fielding requests
and redirecting them to IANA has already taken more time and mindshare than
me popping out a new release with updated data. In hindsight I should have
added an override and made a release months ago.

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

Stuart Bishop <stuart at stuartbishop.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220701/ada3814f/attachment.html>

More information about the tz mailing list