[Python-Dev] Maintaining old releases (original) (raw)

Brett Cannon brett at python.org
Thu Aug 14 05:29:14 CEST 2008

On Wed, Aug 13, 2008 at 4:11 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

There's a difference between never being released, and unavailable in the source repository. So would you have preferred if I had forked another branch that still contained these patches? Such branch can still be added now. Nothing that gets added to the source repository ever becomes unavailable. Re-adding them is fairly easy: they are all in r61179. Going forward, the question would then be if these patches will ever get released. So there could be two branches, one that people can commit arbitrary bug fixes to (which will never be released), and one that gets security patches (which will get released for five years). Of course, I would personally find it fairly confusing to have people commit patches that are explicitly will not be released, and still aren't experimental or private-use.

And toss in having the potential 2.6/2.7/3.0/3.1 branches all at once and that makes having separate security and bug fix branches just not work.

To toss in my opinion (which shouldn't count for too much since I have yet to cut a release), I am mostly with Martin on this one. We currently keep one version back running on the buildbots so we at least have some inkling of what patches do so we can provide some level of quality control on releases (even though we have some red stable buildbots for 2.5 right now). But without running buildbots on the code who knows what a change will do on various platforms. And who wants to deal with a bug report on 2.4 at this point?

Now I would have said that someone could just cut a release if they want and people can just not be expected to backport if they don't feel like it. But then what about when we do fix security issues? If someone does a backport of a security fix but can't run the test suite because that version of Python has not been tested on their OS or buildbot, then that stonewalls their work. I would not want to potentially see this happen.

Basically my opinion boils down to a version should be maintained as long as we have the infrastructure to be testing it regularly on the buildbots (or whatever the equivalent is for our integrated testing). As of right now that means the current version and the trunk. If we actually manage to get the manpower and machines to maintain more, then we can consider maintaining versions longer. But as of right now we don't not have the volunteers to do this and so I don't think we should be considering doing more than what we are doing now.

-Brett

More information about the Python-Dev mailing list