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