[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4