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
What, if any, impact do you think the LSB should have wrt maintaining 2.4? n On 12/4/06, "Martin v. Löwis" <martin@v.loewis.de> 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
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
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 <anthony@interlink.com.au> It's never too late to have a happy childhood.
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
On 12/5/06, Anthony Baxter <anthony@interlink.com.au> 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
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
participants (3)
-
"Martin v. Löwis" -
Anthony Baxter -
Neal Norwitz