On Wednesday 29 May 2002 05:11 pm, Michael Gilfix wrote: ... > get burnt. Perhaps Python should adopt a versioning number such > that major changes occur during odd numbers, etc. Just so users Yep. I proposed this in the very first message of the thread with this subject, about 2 months ago I believe. Linux (and perhaps more relevantly Ruby, a language very close to Python in many respects) use even minor versions for the releases of the stable-track (slow, prudent and backwards-compatible change -- in theory, at least; not sure how good is Ruby at satisfying this promise... Linux is so-so), odd minor versions for the releases of the experimental-track (fast, frequently-released, not necessarily backwards compatible changes). However, after bouncing the idea back and forth a bit, in several variations suggested by various people, Guido ended up rejecting it. It may be satisfactory for Ruby, but he decided that it would not be for Python, no matter how close the two cases appear to others. And he _is_ the BDFL, after all. Some help on this score may hopefully come from the recently formed Python Business Forum. Among other tasks the PBF plans to choose and exhaustively test certain Python releases, proposing to Guido to designate those releases "Python in a tie" (I think GvR came up with this specific monicker), then backporting fixes to them &c to ensure the long period of stability typically desired by commercial end-users (I think the target is 18-24 months vs the 6-8 months target of Python minor releases). I apologize if this summary is in any way imprecise -- http://pbf.nuxeo.org/ has authoritative info. Alex
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