Anthony Baxter <anthony at interlink.com.au> writes:
> In addition, anyone from the Python community is free to suggest
> patches for inclusion. Patches may be submitted specifically for
> patch releases; they should follow the guidelines in PEP 3 [2].
> In general, though, it's probably better that a bug in a specific
> release also be fixed on the HEAD as well as the branch.
I thought the consensus policy was now stronger than this: bugfixes
are tested on the trunk (unless the bug has gone away on the trunk as
part of feature work or something). Submitting a patch that only
applies to release2x-maint is not good form.
> Bug fix releases are expected to occur at an interval of roughly
> six months. This is only a guideline, however - obviously, if a
> major bug is found, a bugfix release may be appropriate sooner. In
> general, only the N-1 release will be under active maintenance at
> any time. That is, during Python 2.4's development, Python 2.3 gets
^
only?
> bugfix releases.
Cheers,
mwh
--
But since your post didn't lay out your assumptions, your goals,
or how you view language characteristics as fitting in with
either, you're not a *natural* candidate for embracing Design by
Contract <0.6 wink>. -- Tim Peters, giving Eiffel adoption advice
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