A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2003-September/037956.html below:

[Python-Dev] Re: [Pydotorg] Documenting branch policy

[Python-Dev] Re: [Pydotorg] Documenting branch policy [Python-Dev] Re: [Pydotorg] Documenting branch policyMartin v. Löwis martin at v.loewis.de
Sun Sep 7 20:16:07 EDT 2003
Greg Ward <gward at python.net> writes:

> Has anyone taken the time to sit down and document the development
> process surrounding release and maintenance branches? 

You mean PEP 6 and PEP 102?

> 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.

> 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.

> <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.

Regards,
Martin

More information about the Python-Dev mailing list

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