Terry Reedy writes:
This strikes me as an improvement, but 'maintain' is close to
'support' and seems to make a promise that might also have
unintended legal consequences. But that is what your legal consel
is for.
Unilateral statements on a web page do not constitute a contract.
Implied
Python can dispose of a raft of bugs present only in the older
versions with WONTFIX at release of a new stable version (after
double-checking that they don't exist in the stable version).
I'm all in favor of formalizing a policy of when Python releases
are produced, and what Python releases,
This PEP attempts to formalize the existing practice, but goes beyond
it in introducing security releases. The addition of security releases
addresses various concerns I heard over the last year about Python
being short-lived. Those concerns are typically raised by Linux
distributors which see
Martin v. Löwis wrote:
Please let me know what you think.
This appears to be an accurate description of the way releases have been
handled for the last few years (which appears to be working well), so +1
here.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
Tim Peters wrote:
[Raymond Hettinger]
...
My intention for the module is to be fully compliant with the spec and all
of its
tests. Code written in other languages which support the spec should expect
to be transferrable to Python and run exactly as they did in the original
language.
Martin v. Löwis writes:
I'm all in favor of formalizing a policy of when Python releases
are produced, and what Python releases, and what kinds of changes
they may contain. However, such a policy should be addressed
primarily to contributors, as a guidance, not to users, as
a promise.
I'm all in favor of formalizing a policy of when Python releases
are produced, and what Python releases, and what kinds of changes
they may contain. However, such a policy should be addressed
primarily to contributors, as a guidance, not to users, as
a promise. So I have problems
Martin v. Löwis writes:
A security fix must not risk the releasability of the branch, i.e. the
maintenance branch should be in a shape to produce a release out of it
as-is at all times.
[...]
Security releases should be made at most one year after a security
patch has been committed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 12, 2007, at 4:29 AM, Martin v. Löwis wrote:
This PEP attempts to formalize the existing practice, but goes beyond
it in introducing security releases. The addition of security releases
addresses various concerns I heard over the last year
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 12, 2007, at 9:02 AM, Stephen J. Turnbull wrote:
I don't understand the point of a security release made up to a year
after commit, especially in view of the first quoted paragraph. A
commit may not be made without confirming *immediate*
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| The impression that many people (including python-dev regulars) have
| that there is a policy of support for both the current release
| (2.5) and the (still very widely used) previous release (2.4) is a
| real
ACTIVITY SUMMARY (05/06/07 - 05/13/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1650 open ( +0) / 8584 closed ( +0) / 10234 total ( +0)
Average duration of open issues: 791 days.
Terry Reedy writes:
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| The impression that many people (including python-dev regulars) have
| that there is a policy of support for both the current release
| (2.5) and the (still very widely used) previous
On 5/12/07, Tracker [EMAIL PROTECTED] wrote:
[...]
I clicked on the tracker link out of curiosity noticed that the
tracker has been spammed -- issues 1028, 1029 and 1030 are all spam
(1028 seems a test by the spammer).
These issues should be deleted and their creator's accounts disabled.
BTW
On 5/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 5/12/07, Tracker [EMAIL PROTECTED] wrote:
[...]
I clicked on the tracker link out of curiosity noticed that the
tracker has been spammed -- issues 1028, 1029 and 1030 are all spam
(1028 seems a test by the spammer).
We know. Skip is
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| FWIW, after Martin's explanation, and considering the annoyance of
| keeping updates sync'ed (can PEPs be amended after acceptance, or only
| superseded by a new PEP, like IETF RFCs?),
Informational PEPs often get
16 matches
Mail list logo