[Python-Dev] Maintaining old releases
barry at python.org
Thu Aug 14 06:08:45 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
On Aug 13, 2008, at 7:11 PM, Martin v. Löwis 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.
Sure, but nobody's going to dig through commit messages to dig out
I'm not sure what I would have preferred. Really, I was mostly fine
with the decision to do as we did. But if we stick with the policy
you propose (which I'm not sure is completely nailed down yet), then I
will be sure not to waste my time on closed releases next time.
> Going forward, the question would then be if these patches will ever
> get released. So there could be two branches, one that people can
> 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.
No, I don't think we need another branch per version.
I'm clearly in the minority, and I've said my peace on the subject, so
I'll let it go. Moving forward, I do want to make sure we communicate
to our users and developers, exactly what the policy is, with enough
advanced warning for each version so that they can plan ahead and
won't waste time. Ideally, we would lay this out when we plan the
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-Dev