The ROOT source tarball at ftp://root.cern.ch/root/ occasionally changes without any obvious points of reference. This concerns me a bit, as I am never really sure what version of the ROOT source code I am getting. For example, we keep a local mirror of the ROOT ftp site, and I was surprised this morning when a new version of `root_v2.22.source.tar.gz' suddenly appeared. This file has substantive differences from the one which was available after Rene's announcement of the availability of root 2.22.09 last Friday on 1997.07.17 (see http://root.cern.ch/root/roottalk/roottalk99/1542.html). I had always been under the impression that `root_v2.22.source.tar.gz' was the reference from which the most recent ROOT 2.22 binaries were based on. Is this correct? Or is the purpose of `root_v2.22.source.tar.gz' just a rolling snapshot? I went back and looked at our mirror logs which showed that `root_v2.22.source.tar.gz' has indeed changed in between the binary releases, so perhaps its purpose is as a snapshot after all, but clarification on this point would be helpful. Whatever the intention of `root_v2.22.source.tar.gz' is (i.e. either as a reference to the binaries or just an arbitrary snapshot), may I suggest that these tarballs be versioned and created such that they unpack into their own top-level directory. For example, if `root_v2.22.source.tar.gz' is supposed to be a reference to the 2.22.09 binaries, then rename the tarball `root-2.22.09.tar.gz' and have it unpack into its own subdirectory called `root-2.22.09' (for example). Regardless of what the subdirectory is called, the benefit is that the tarball will never be changed (i.e. right or wrong, it is a release that is forever frozen in time that everyone can synchronize to) and it is self contained (i.e. it unpacks into its own sandbox). A source tarball that is intended to be a snapshot, on the other hand, could follow the common idiom of encoding the date of the snapshot into the name of the tarball, i.e. todays new source tarball could have been named `root-19990717.tar.gz'. Another benefit of having points of reference like I am describing would be that patches could then easily be provided which bring one version of the root source code in line with another. For example, the patch which brings last Fridays version of the root 2.22 source code up to todays version of the root 2.22 source code is only about 6k compressed. Compare this with the 3.1 Meg compressed source tarball that is currently required to download the ROOT source code. A remote CVS repository of the ROOT sources with anonymous checkout would solve all of these problems. Sites, and even groups within sites, could then standardize on whatever version of the ROOT sources which they needed. For example, one group at SLAC is currently stuck on ROOT 2.22.04 due to some incompatibilities with later versions of ROOT, but other groups at SLAC are using later versions of ROOT. If the ROOT maintainer for SLAC needed to recompile an older version of ROOT (which, in fact, we have), it would be very difficult to do so since he doesn't have convenient access to specific versions of the ROOT sources. -- Matthew D. Langston SLD, Stanford Linear Accelerator Center langston@SLAC.Stanford.EDU
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:36 MET