> > Maintenance branches are for bug fixes > > <em>only</em>; > > This question is heavily debated. Alex Martelli, for example, favours > a policy where new (in a strict sense) features are acceptable if they > don't break anything, and are "minor", in some sense. Which pretty much matches the policy I used informally before all this was written down in PEPs. (Admittedly, 1.5.2 went way beyond this, and I don't wish to go back to those days.) > > maintaining backwards compatibility at every level is imperative. > > (In particular, all extension modules and bytecode for Python > > 2.<em>x</em>.<em>y</em> must continue to work with Python > > 2.<em>x</em>.<em>y+1</em> -- binary compatibility in the C API and > > bytecode must be maintained.)</p> > > Even that requirement got dropped at one time, on grounds of the > specific API being irrelevant for all practical applications. So the rule becomes all extension modules and bytecode "in actual use" must continue to work. BTW I don't think we've ever changed the bytecode in a micro release after 1.5.2, and I want to continue to be strict about that. > > <p>Any Python developer may checkin bug fixes on a maintenance branch; > > it is the release manager's responsibility to create the maintenance > > branch after releasing a new major Python version.</p> > > The typical guidelines apply: If in doubt, post to SF. Or discuss it here. (I personally don't see new bugs on SF, but I do read all of python-dev -- though this should come as no surprise, as according to Brett's stats, I also write most of it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
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