On Sat, 24 Mar 2001 08:33:59 -0500, Guido van Rossum <guido@digicool.com> wrote:
> OK, here's what I've done. I've done a new cvs export of the r21b2
> tag, this time *without* specifying -kv.
This was clearly the solution to *this* problem ;-)
"No code changes in CVS between the same release" sounds like a good
rule.
> The question is, should we bother to make the code robust under
> releases with -kv or not?
Yes.
People *will* be incorporating Python into their own CVS trees. FreeBSD
does it with ports, and Debian are thinking of moving in this direction,
and some Debian maintainers already do that with upstream packages --
Python might be handled like that too.
The only problem I see if that we need to run the test-suite with a -kv'less
export. Fine, this should be part of the release procedure.
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.
Since "smart" means just
__version__ = [part for part in "$Revision$".split() if '$' not in part][0]
We can just mandate that, and be safe.
However, whatever we do the Windows build and the UNIX build must be the
same.
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.
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
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