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

Jack Diederich jack at performancedrivers.com
Tue Nov 4 15:33:06 EST 2003

On Mon, Nov 03, 2003 at 10:36:33AM -0500, Jeremy Hylton wrote:
> On Mon, 2003-11-03 at 07:47, Alex Martelli wrote:
> > 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)? 
> It is customary to fix things on the trunk first, then backport to
> branches where it is needed.  People who maintain branches often watch
> the trunk to look for things that need to be backported.  As far as I
> know, no one watches the branches to look for things to port to the
> trunk.  It may get lost if it's only on a branch.
> The best thing to do is your option [a]: Fix it in both places at once. 
> Then there's nothing to be forgotten when time for a release rolls
> around.

If we aren't using CVS tagging features, it just falls under personal
preference.  If we are, it is easier to import all the changes from
the branch to the trunk, tag it is 'import_to_trunk_N' and then
next time something changes just look at the diff between the
'import_to_trunk_N' tag to now, mark as 'import_to_trunk_N+1', rinse
and repeat.  Doing it w/ tags has the benefit that you can do
a one-liner that says 'try to import any changes from the branch.'


More information about the Python-Dev mailing list