On Monday 08 April 2002 22:00, Guido van Rossum wrote: > [Guido] > > > > I'm not sure the stable track would differ in practice from what > > > we're already doing with 2.1.3 and 2.2.1. > > [Alex] > > > I think the clear separation would help. Consider a book author: what > > release is he or she going to focus on? He or she clearly wants to > > target the release that is CURRENT when the book comes out > > And there's the crux -- that one is still EXPERIMENTAL while the book > is being written. 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. > > Thus the clear message "this is current, stable, actively maintained", > > even by itself, is going to attract some more volunteer active > > maintenance -- not quite a self-fulfilling prophecy, but... it does not > > need to follow that the experimental release gets less -- if the pie > > grows, both slices may get larger. Besides, "experimental" has its > > own allure -- you could call it "leading-edge" internally:-). > > 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. > I note that for things like FreeBSD or Debian (or Linux, for that > matter) the issues are fundamentally different than for Python. It's Yes -- different scale, more fragmentation, etc. > Maybe there's no way out: as long as the development of the language > goes at the pace it goes, there's not much we can do to prevent > language users to see frequent releases and frequent (small) changes. > If we reduce stable releases to once a year, that's still too frequent > for some (Rubin has requested 2-3 years between releases) while others > will be so eager to use new features that they'll risk using the > CVS head -- and then end up hating it for its instability (because all > they want is the "big" new features, not the day-to-day churn). 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). No, that would NOT satisfy those who insist on 2.(N+1) not running any code that 2.N didn't -- or worse, any code that 1.5.2 didn't. I don't think there is ANY way to satisfy this request, except burying "Python" and giving a new name to the language (Monty?-). We can't satisfy EVERYbody, I think. But I hope we won't take this as an excuse to do nothing at all:-). 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