On 2012-09-13 15:52, Paul Eggert wrote:

On 09/13/2012 12:08 AM, Paul Eggert wrote:

...

Here are links to the release files:

http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz

ftp://ftp.iana.org/tz/releases/tzcode2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2012f.tar.gz

As Jonathan Leffler noted, there's a typo in that first URL; it should have been

http://www.iana.org/time-zones/repository/releases/tzcode2012f.tar.gz

Sorry about the confusion.

Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

I can't see a reason for a shared version number. Sending out a "new" package that is actually just the old package with a new number attached is confusing at best. It's more helpful for the version number to say when the package in question has changed. So how about two packages, with two separate version numbers? If you want to avoid confusion from similar-looking version strings that don't mean the same thing, you could use names like tzdata2012f for tzdata, and tzcode2012-2 for tzcode. That way no one can think that a given tzcode "goes with" a given tzdata. paul On Sep 14, 2012, at 10:35 AM, Paul Eggert wrote:

On 09/14/2012 01:41 AM, Ian Abbott wrote:

...

Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)?

That's the way things are currently set up, yes. It is a bit of an annoyance, and perhaps we can think of a better way to do it. One possibility would be to put the Makefile (which has the version number) into both distributions.

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 on the new data, and produce binary zoneinfo files differing only in the changed rules. Crudely, if zic runs without error and zdump produces changes that are explained by the change notes, then tzcode doesn't have to be updated.

On 2012-09-14 15:35, Paul Eggert wrote:

On 09/14/2012 01:41 AM, Ian Abbott wrote:

...

Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)?

That's the way things are currently set up, yes. It is a bit of an annoyance, and perhaps we can think of a better way to do it. One possibility would be to put the Makefile (which has the version number) into both distributions.

I was thinking more on the lines of allowing the Makefile to build both the tzcode and tzdata packages, but conditionally uploading one or both as "official" releases based on what's changed since the previous official release of each (an "executive decision"). -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

Date: Fri, 14 Sep 2012 10:09:41 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <505364D5.2050208@cs.ucla.edu> | A downside of both of these | approaches, though, is that the two version numbers would be | in different places, making it more likely that I'll forget | to update one or the other. No, you don't want to do it that way, you want a single file in the repository that is the version number, and then the Makefile target that creates the distribution files incorporates that version number in whatever places in the eventual distribution it is decided that it should live (Makefile, zone.tab, README.xxx or even in every file if desired) just before making the tar file. That is, the distributed tgz is made out of (slightly) modified copies of (some of) the files from the repository, not those files directly. The only place in the repository that the version number is ever seen is in that one single file, and that one file I would not include in either the data or source distritions (it isn't needed to build or use the code or data, only to make distributions, and only the owner of the repository needs to be able to do that). You don't want to include it in just one tgz file, as then whever that file happens to be an older version than the other, this new file looks to have incorrect contents, and you don't want to include it in both, as that leads to races on extraction (which version you get depends which of the tgz's is extracted last). The strategy of just not uploading the code tgz when it hasn't changed means that the eventual distributed pair of files (files with different versionids in their names) would end up with an incorrect version number (as it is now in the Makefile) for the data (worse than not having one at all). And of course, people who only download the data (relying upon their system's integrated code version) don't get a version number at all (except the one in the tgz filename). kre

Date: Fri, 14 Sep 2012 16:33:03 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <5053BEAF.2010607@cs.ucla.edu> | That "slightly" and "some of" are bothersome. The "some of" shouldn't be, that was just meant to indicate that we (or you) get to decide which files get the version number in them, which might be some of the files, or all of them, a choice we make - after that it's irrelevant to this issue. The "slightly modified" part sounds not so good, but in reality, it is what we're doing now anyway, and what just about everyone does ... the real master files are the ones in the git repository (or when ado was doing it, his sccs repository, or for the short while I did it, RCS) and those we don't distribute - to truly distribute unmodified master files, allowing everyone to do everything, we'd need to distribute via "git clone" or whatever git has to make repository copies (I'm not a git user, if that isn't obvious). We could do that, but for 99% of the users it is useless overhead and unnecessary extra work to deal with. Given that we're modifying the files anyway, does it really matter whether or not the distribution contains exactly the same bits as whatever git's equivalent of the sccs/rcs "checkout" commands produce? That is, we do a checkout, then one small extra post-processing step, and the results of that are the distribution. | The distributed files should | have all the info needed to make the distribution, so that the | whole procedure is self-documenting and automatic. Self documenting and automatic, absolutely. All the info, just almost, and just because there's no safe way to make that actually happen the way we have historically done the distributions (as the master copy has a single version number that applies to everything, but everyone else gets two potentially different versions, one for the code, and one for the data). If we abolished the code/data distinction, then we could distribute everything. Otherwise we distribute everything, except one 5 byte (well, 6 including the \n) file that contains "2012f" (or whatever version we're up to). | Yes, and that's the advantage of putting the data version number | into (say) zone.tab. Where it goes isn't as important as that it is in some file distributed in tzdataNNNNx.tgz and not distribued in tzcodeNNNNx.tgz (and vice versa for the code version number). It could be in any single file that qualifies in each (like Makefile and zone.tab) or it could be in every file. This should really be based upon what is best for the users, as it makes almost no difference to anything else. | So perhaps we should do it that way, even if it's a bit more | error-prone because the two version numbers are in different files. Please don't jumble the decisions on what the results should look like, with how they should be constructed - while those are related, they don't have to be even close to the same. It is trivially easy to avoid the "bit more error-prone" by making sure that there is exactly one version number to manage, and then using automation to apply that version number to the distribution files in the proper way. Given that it is so easy, I think we should do that -- but as this affects operations that only you ever perform, it really comes down to what works best for you (as long as the end result looks OK, none of the rest of us will care much how much work you need to do to get it to that state...) I haven't just written the few lines of shell script (that would be implemented as Makefile recipe lines) and sent them, as it isn't clear to me that the simpler solution of just abandoning the split code & data distributions, and going back to a single tgz file, with a single trivial version number (the way it was originally,) isn't also the better solution. There's almost no-one concerned with 1200bps uucp data transfers any more... kre