[Python-Dev] Maintaining old releases

Barry Warsaw barry at python.org
Thu Aug 14 06:08:45 CEST 2008

Hash: SHA1

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  
those patches.

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  
> 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.

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.

- -Barry

Version: GnuPG v1.4.9 (Darwin)


More information about the Python-Dev mailing list