[ disclaimer: I too am just a downstream maintainer ] Stuart Bishop via tz <tz@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