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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
