[Python-Dev] check-in policy, trunk vs maintenance branch
jeremy at zope.com
Tue Nov 4 16:59:19 EST 2003
On Tue, 2003-11-04 at 15:33, Jack Diederich wrote:
> 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
I think there's more than personal preference involved. We ought to be
consistent in how we apply patches to avoid missing things.
> 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.'
The branch has bug fixes and changes that don't necessarily show up on
the trunk. For example, a bug that exists in code that was removed or
completely rewritten on the trunk. It also doesn't address the
stability issue: A maintenance branch gets less testing, and committers
should be cautious about changes. Committing on the trunk first gives
you a chance to test out the changes there and get feedback.
More information about the Python-Dev