Michael Foord wrote: > M.-A. Lemburg wrote: >> Why don't we just mark 3.0.x as experimental branch and keep updating/ >> fixing things that were not sorted out for the 3.0.0 release ?! I think >> that's a fair approach, given that the only way to get field testing >> for new open-source software is to release early and often. >> >> A 3.1 release should then be the first stable release of the 3.x series >> and mark the start of the usual deprecation mechanisms we have >> in the 2.x series. Needless to say, that rushing 3.1 out now would >> only cause yet another experimental release... major releases do take >> time to stabilize. >> >> > +1 > > I don't think we do users any favours by being cautious in removing / > fixing things in the 3.0 releases. I have two main reactions to 3.0. 1. It is great for my purpose -- coding algorithms. The cleaner object and text models are a mental relief for me. So it was a service to me to release it. I look forward to it becoming standard Python and have made my small contribution by helping clean up the 3.0 version of the docs. 2. It is something of a trial run that it should be fixed as soon as possible. I seem to remember sometning from Shakespear(?) "If it twer done, tis best it twer done quickly". Guido said something over a year ago to the effect that he did not expect 3.0 to be used as a production release, so I do not think it should to treated as one. Label it developmental and people will not try to keep in use for years and years in the way that, say, 2.4 still is. tjr
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