[me] > > And there's the crux -- that one is still EXPERIMENTAL while the book > > is being written. [Alex] > That depends on how often the experimental branch is fed back into a > new stable one. If every 6 months, well, sure. But I think it > would not need to be anywhere as frequent. Neil suggests 18-36 months. Maybe we should put off 2.3 until, oh, late 2003? And plan to shove a whole lot more new features into it? And maybe move some minor features into the 2.2.x branch? (I hardly dare suggest bools. :-) > > So which distinction should we make? In a previous msg you disliked > > STABLE vs. CURRENT. Would you prefer STABLE vs. EXPERIMENTAL or > > CURRENT vs. EXPERIMENTAL? > > I think both sound very good in the abstract (while stable vs current > does not). It seems to me that stable vs experimental is slightly > preferable because it appears to draw a neater distinction, and > some connection of 'current' to other-than-stable might otherwise > attach from (e.g.) the BSD terminology. But there might be some > other consideration that doesn't come to my mind right now that > makes current/experimental preferable. OK, STABLE vs. EXPERIMENTAL it is. > There may not be ONE way out -- but maybe TWO tracks would do, > instead. On the stable track, releases that could break previously > correct code would be highly infrequent; on the experimental ones, > releases would be frequent -- ideally frequent enough that people > wouldn't go to CVS unless they're interested in contributing to the > internals, but could feel they're "on top of the leading-edge > RELEASE" (aka the experimental-track release). This also sounds similar to what Neil proposes. So maybe we're closing in to consensus: significantly slower "major" releases (like 2.3), more effort in "bugfix" releases (like 2.2.1) and more of those. And guess what, Anthony Baxter has offered to be the 2.2.2 releasemeister. I also like Andrew's idea of making everybody commit their changes in both branches -- to scale the effort of keeping the maintenance branch up-to-date. --Guido van Rossum (home page: http://www.python.org/~guido/)
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