On Wed, Jan 28, 2009, 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.
Speaking as the original author of PEP6 (Bug Fix Releases), this sounds like a reasonable middle ground. I certainly advocate that nobody consider Python 3.0 for production software, and enshrining that into the dev process should work well. At the same time, I think each individual change that doesn't clearly fall into the PEP6 process of being a bugfix needs to be vetted beyond what's permitted for not-yet-released versions. The problem is that the obvious candidate for doing the vetting is the Release Manager, and Barry doesn't like this approach. The vetting does need to be handled by a core committer IMO -- MAL, are you volunteering? Anyone else? Barry, are you actively opposed to marking 3.0.x as experimental, or do you just dislike it? (I.e. are you -1 or -0?) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. _______________________________________________ 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
