On Tuesday 09 April 2002 04:51 pm, Skip Montanaro wrote: > >> Over time people should become aware that odd-numbered minor > >> releases are always development releases and are not to be relied > >> upon. > > Michael> In which case you might as well not release "odd-numbered > minor Michael> releases" becuase 90+% of the people who would use them get > Michael> Python from CVS anyway. > > You still need releases. I'm advocating a completely different way of > deciding when to release, however. Instead of generating PEP 283 (Python > 2.3 Release Schedule), the timing of when to split the experimental branch > should be driven by completeness of the functional goals for that branch > and the bug fix rate for that branch. This is not a commercial enterprise. I find this line of reasoning VERY convincing -- I hadn't thought of it myself, but you make me wish I had:-). > I don't think there is a "market window" that has to be hit that should > dictate, "we have to release 2.3 in mid-August, regardless of what else is > going on." When you have a time-driven schedule, I think there is a > temptation to find "something new" to put into every release. Well put! Goal-driven releases, rather than time-driven ones, seem important for both tracks, the stable and the experimental one. 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