[Python-Dev] check-in policy, trunk vs maintenance branch
aleaxit at yahoo.com
Mon Nov 3 07:47:10 EST 2003
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)?
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, [b] always to the trunk but
to the branch only once one comes around to that, [c] always to the branch but
to the trunk only once one comes around to that, ...?
Oh, incidentally, if it matters -- most were docs issues, including as "docs"
also some changes to comments that previously were misleading or ambiguous.
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.
More information about the Python-Dev