Something that came up in the 2.3 alfa/beta/release cycle is that there
is a buglet
in our version numbering scheme. We use "major.minor" as the indicator
of binary
compatibility, and hence use "lib/python2.3" to put things, distutils
uses "2.3"
in its build directory and distribution filenames, etc.
There are exceptions to this binary compatibility rule, however, and
that are the
alfa and beta releases: these are explicitly not guaranteed to be
compatible. This
problem has always existed, but as far as I know it was theoretical
until Apple shipped
a Python 2.3 beta with their Panther beta. All betas, but still this
means that there
is now a much bigger chance than their ever was of people trying to use
things built
for 2.3final with 2.3b2, or people building modules with 2.3b2 for
quite some time,
which others will then try to install into 2.3final.
I think it's a good idea to fix this. I thought I had an algorithm to
do this
using '.'.join(version.split('.')[:2]) in stead of version[:3], but
unfortunately
this will make the release candidates also not use "python2.3", and I
think for these
we definitely want to use the final names. Still, an algorithm
shouldn't be rocket
science:-)
Opinions?
--
- Jack Jansen <Jack.Jansen@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma
Goldman -
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