[Python-Dev] test_minidom crash
Tim Peters
tim.one@home.com
Sat, 24 Mar 2001 15:49:46 -0500
[Moshe]
> ...
> I just went through the core grepping for '$Revision' and it seems
> this is the only place this happens -- all the other places either put
> the default version (RCS cruft and all), or are smart about handling it.
Hmm. Unless it's in a *comment*, I expect most uses are dubious. Clear
example, from the new Lib/unittest.py:
__version__ = "$Revision: 1.2 $"[11:-2]
Presumably that's yielding an empty string under the new tarball release.
One of a dozen fuzzy examples, from pickle.py:
__version__ = "$Revision: 1.46 $" # Code version
The module makes no other use of this, and since it's not in a comment I have
to presume that the author *intended* clients to access pickle.__version__
directly. But, if so, they've been getting the $Revision business for years,
so changing the released format now could break users' code.
> ...
> However, whatever we do the Windows build and the UNIX build must be
> the same.
*Sounds* good <wink>.
> I think it should be possible to build the Windows version from the
> .tgz and that is what (IMHO) should happen, instead of Tim and Guido
> exporting from the CVS independantly. This would stop problems like the
> one Tim and I had this (my time) morning.
Ya, sounds good too. A few things against it: The serialization would add
hours to the release process, in part because I get a lot of testing done
now, on the Python I install *from* the Windows installer I build, while the
other guys are finishing the .tgz business (note that Guido doesn't similarly
run tests on a Python built from the tarball, else he would have caught this
problem before you!).
Also in part because the Windows installer is not a simple packaging of the
source tree: the Windows version also ships with pre-compiled components for
Tcl/Tk, zlib, bsddb and pyexpat. The source for that stuff doesn't come in
the tarball; it has to be sprinkled "by hand" into the source tree.
The last gets back to Guido's point, which is also a good one: if the
Windows release gets built from a tree I've used for the very first time a
couple hours before the release, the higher the odds that a process screwup
gets overlooked.
To date, there have been no "process bugs" in the Windows build process, and
I'd be loathe to give that up. Building from the tree I use every day is ...
reassuring.
At heart, I don't much like the idea of using source revision numbers as code
version numbers anyway -- "New and Improved! Version 1.73 stripped a
trailing space from line 239!" <wink>.
more-info-than-anyone-needs-to-know-ly y'rs - tim