Date: Fri, 14 Sep 2012 10:52:06 -0400 From: Bennett Todd <bet@rahul.net> Message-ID: <CAA9gXs-zrwxRYBsav4QRVppFwHgZg-3ZpNqqr0964goeRgSDZg@mail.gmail.com> | I believe a question is the possibility of a change in the zone data | requiring an update to zic. If that's right, perhaps the release cutting | procedure could test that older versions of zic work ... No, for the issue at hand, it is nothing like that complex. if any of the source (code) files have been updated, a new tzcode distribution is needed, if any of the data files have been updated, a new tzdata distribution is needed. For deciding when to make new releases it is that simple. The version in Makefile thing is also simple - just remove it again. It never was there before, and aside from (perhaps) being used to make the tgz filenames, can't be being used for anything (the distribution filenames could come from somewhere else). The version was added mostly because people wanted a way to know what version they had, without keeping the tgz file around - perviously the tgz filename was the only place the version was identified. It doesn't need to be in the Makefile for that, we could just have README_CODE and README_DATA files (one in each distribution) that give the version (and perhaps a few other lines of useful info). Those files could even be built (when needed) from a master file (not distributed perhaps) that contains the current version identifier (which would be used to make whichever, or both, of the code & data files is needed, and then incremented). There are of course a zillion other ways that this could be handled, including (if the iana site access Paul has permits it) just not bothering to update whichever of the distribution files hasn't changed (after doing everything else that builds both of them - just remove the one that isn't needed and keep the old distribution). Or we could completely change the distribition format and make the whole question moot - these days there's probably no longer much reason for actually keeping the code & data distributions separate, we could just have one single distribution, or we could have one complete distribution, and perhaps a data only version that is always updated when the main file is updated for those people who want data only (wanting source only is so rare it can be ignored). And I'm sure there are plenty of other ways that we could "fix" this problem - but I don't thing fixing it is urgent. We're going to need tzdata2012g very soon now, as that Western Samoa transition is in just over 2 weeks ... the people there said my patch "didn't work" but didn't tell me in what way, or what problem they had (yet anyway), I'm awaiting a reply - but it is Saturday there already... (If anyone else detected a problem, please let me know - if you usually test these things, and didn't yet, please do). When that's ready if we also end up with a tzcode2012g that's a null change from tzcode2012f (and 2012e) that's not really a problem - just as long as the release info says (as it did this time) that there are no changes, so we can just ignore it (I ignore tzcode changes - aside from putting the distribution file on munnari's tz archive - most times anyway, since the most frequent changes are to the html files (etc), and I have no direct use for any of those, I only bother processing tzcode updates when the C code has changed - and that's not very common. The release notes are how I find out what I need to do). kre