A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039903.html below:

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

[Python-Dev] check-in policy, trunk vs maintenance branchAlex Martelli 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.


Thanks,

Alex


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4