[Python-Dev] LSB: Selection of a Python version
At the LSB meeting, there was a brief discussion of what Python version should be incorporated into LSB. This is more an issue if ABI compatibility for the C ABI is desired, but even if only script portability is a goal, application developers will need to know what APIs they have available in LSB 3.2 and which they don't. LSB codifies existing practice, rather than defining "anticipating" standards, so things get only into LSB if they are already commonplace in distributions. Currently, Python 2.4 is widely available in Linux distributions; Python 2.5 is not and (apparently) will not be included in the next RHEL release (which apparently is coming soon). So it looks like LSB will standardize on Python 2.4 (which will also be the default version in the next Debian release). Regards, Martin ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
What, if any, impact do you think the LSB should have wrt maintaining 2.4? n On 12/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > At the LSB meeting, there was a brief discussion of what Python > version should be incorporated into LSB. This is more an issue > if ABI compatibility for the C ABI is desired, but even if only > script portability is a goal, application developers will need > to know what APIs they have available in LSB 3.2 and which they > don't. > > LSB codifies existing practice, rather than defining "anticipating" > standards, so things get only into LSB if they are already > commonplace in distributions. Currently, Python 2.4 is widely > available in Linux distributions; Python 2.5 is not and (apparently) > will not be included in the next RHEL release (which apparently > is coming soon). > > So it looks like LSB will standardize on Python 2.4 (which will also > be the default version in the next Debian release). > > Regards, > Martin > ___ > 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/nnorwitz%40gmail.com > ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
Neal Norwitz schrieb: > What, if any, impact do you think the LSB should have wrt maintaining 2.4? People at the meeting specifically said whether security patches would still be applied to older releases, and for how many older releases. Linux distributors are hesitant to make commitments to maintain a software package if they know that their upstream source doesn't provide security patches anymore. I think we should come up with a policy for dealing with security patches (there haven't been that many in the past, anyway); I believe users (i.e. vendors in this case) would be happy with the procedure we followed for 2.3: just produce a source release integrating the security patches; no need for binary releases (as they will produce binaries themselves). So I think a public statement that we will support 2.4 with security patches for a while longer (and perhaps with security patches *only*) would be a good thing - independent of the LSB, actually. Regards, Martin ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
On Tuesday 05 December 2006 17:30, Martin v. Löwis wrote: > People at the meeting specifically said whether security patches > would still be applied to older releases, and for how many older > releases. Linux distributors are hesitant to make commitments to > maintain a software package if they know that their upstream > source doesn't provide security patches anymore. I agree we should have a written policy. At the moment, my policy is this: normal bugfixes for 2.5 critical crasher bugfix releases for 2.5 and 2.4 security bugfix releases for 2.5, 2.4, and 2.3. I'm planning on dropping 2.3 from this list sometime next year. After that, I guess we can produce officially blessed patches or something. > I think we should come up with a policy for dealing with security > patches (there haven't been that many in the past, anyway); I > believe users (i.e. vendors in this case) would be happy with the > procedure we followed for 2.3: just produce a source release > integrating the security patches; no need for binary releases (as > they will produce binaries themselves). Depends - while 2.4 is officially "retired" now, if a security bugfix that affects windows/OS X comes up, I think we should still cut binary releases. > So I think a public statement that we will support 2.4 with > security patches for a while longer (and perhaps with security > patches *only*) would be a good thing - independent of the LSB, > actually. Well, I don't know what sort of public statement you want to issue, but will this do? (Wearing my release manager hat) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
Anthony Baxter schrieb: >> So I think a public statement that we will support 2.4 with >> security patches for a while longer (and perhaps with security >> patches *only*) would be a good thing - independent of the LSB, >> actually. > > Well, I don't know what sort of public statement you want to issue, > but will this do? (Wearing my release manager hat) This would be a good statement, but I have also a set of policies in mind that clarify what a "security bugfix" is, so people know what kind of changes they get when they install a new version that only has security bugfixes. I believe this guarantee works in two ways: we should guarantee that we will accept security bugfixes, but we should also guarantee that we *only* accept security bugfixes (and perhaps critical crashers - although they overlap in the denial-of-service field). Regards, Martin ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
On 12/5/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > > > So I think a public statement that we will support 2.4 with > > security patches for a while longer (and perhaps with security > > patches *only*) would be a good thing - independent of the LSB, > > actually. > > Well, I don't know what sort of public statement you want to issue, > but will this do? (Wearing my release manager hat) I think we should document our intentions in the release PEP (or some other PEP possibly). Should we state that we will support version x.y for N years after initial release or based on version numbers such as x.(y-N) where y is the current version and N is a small number? I'd prefer the time based approach because it seems much more common. For reference here are some release dates: 2.2: 2001-12-21 2.3: 2003-07-29 2.4: 2004-11-30 If we stopped supporting 2.3, that would mean we support for 2-3 years. n ___ 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
Re: [Python-Dev] LSB: Selection of a Python version
Neal Norwitz schrieb: > I think we should document our intentions in the release PEP (or some > other PEP possibly). Should we state that we will support version x.y > for N years after initial release or based on version numbers such as > x.(y-N) where y is the current version and N is a small number? > > I'd prefer the time based approach because it seems much more common. > For reference here are some release dates: > > 2.2: 2001-12-21 > 2.3: 2003-07-29 > 2.4: 2004-11-30 > > If we stopped supporting 2.3, that would mean we support for 2-3 years. I like Anthony's view of having three modes of maintenance: general bug fixes, serious crashers, and security fixes. We should continue to have general bug fixes only for the most recent feature release (i.e. 2.5 at the moment). At the rate at which security fixes are reported, it should be possible to keep 2.3 supported (for security patches only) for quite some time longer. I'm not sure about "serious crashers", as I don't have a feeling how often they are reported and how difficult they are to backport. For many of these, it's often the case that it is bad coding on the application's side, in which case I think the application should just work-around when it wants to support old Python versions. Those are typically not security-relevant, at least not if you can't force the crash by passing bad input data (people accepting arbitrary code from untrusted users in their programs are on their own, anyway - since we removed the rexec module). Regards, Martin ___ 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
