[Python-Dev] Maintaining old releases
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