[Python-Dev] check-in policy, trunk vs maintenance branch

Martin v. Löwis martin at v.loewis.de
Mon Nov 3 17:43:22 EST 2003

Alex Martelli <aleaxit at yahoo.com> writes:

> I made a few bugfix check-ins to the 2.3 maintenance branch this
> weekend and Michael Hudson commented that he thinks that so doing is
> a bad idea, that bug fixes should filter from the 2.4 trunk to the
> 2.3 branch and not the other way around.  Is this indeed the policy
> (have I missed some guidelines about it)?

Atleast that's the policy I was following, indicating backports with
"backported to 2.3" in the checkin message.

> I guess for this round of fixes I will find the time to forward-port them to 
> the 2.4 trunk (in AMPLE time for a 2.4 release -- as 2.3.3 is going to come 
> well before 2.4 releases, the other way 'round wouldn't be quite so sure:-),
> but what about the future?  Should fixes applicable to both 2.3.* and 2.4
> be made [a] always to both trunk and branch, 

I prefer to do them on both the trunk and the branch
simultaneously. Having them on the branch simplifies the life of the
release manager, and having them on the trunk gives them atleast some
testing. I had to back out both patches occasionally, but this is not
a bug problem unless a release of the branch is imminent.

> Oh, incidentally, if it matters -- most were docs issues, including
> as "docs" also some changes to comments that previously were
> misleading or ambiguous.

It does matter. For doc changes, any kind of improvement is acceptable
(IMO), as there is no risk of breaking existing applications.

> I guess that my problem is that I think of 2.3.* fixes as things
> that will be useful to "the general Python-using public" pretty
> soon, with 2.4 far off in the future, so that it appears to me that
> trying to make 2.3.* as well fixed as possible has higher priority.
> But if that conflicts with policy, I will of course change anyway.

If you don't forward-port your changes, nobody will. So you satisfy
the general public now, with a view of taking corrections away from
them in the future.


More information about the Python-Dev mailing list