[Python-Dev] TRUNK UNFROZEN (release is done)

"Martin v. Löwis" martin at v.loewis.de
Wed Oct 27 00:15:54 CEST 2004

Jim Fulton wrote:
> With subversion, every revision is is effectively a tag.  Merging
> is usually just a matter of merging differences between 2
> repository revision numbers.  This makes a huge difference when
> multiple files are involved.

Ah, that. I don't worry about this difference too much. When I apply
a change, it usually comes from SF, where it usually is in the form
of a patch. So applying the patch to both the HEAD and a maintenance
branch is:

cd py2.4
cvs up
patch -p0 < /tmp/name_of_patch
(make, test, etc)
cvs commit

cd ../py2.3
cvs up
patch -p0 < /tmp/name_of_patch
(make, test, etc)
cvs commit

To my understanding, you are saying it is very much the same for svn.
The only difference is that back-porting of patches afterwards is
easier for svn - that may be true, but is irrelevant for applying
SF patches.

> I find that having a separate branch makes it absolutely
> unambiguous that only bug fixes should be created there. <shrug>

I don't think it makes it so for all developers. Between branching
the beta, and the final release, it might be still reasonable to
add features (in a strict sense) - the same is actually true after
the release. Whether a branch is created or not would be immaterial
to me.

> Python hasn't always done a good job of avoiding feature changes
> during beta cycles or on maintenence branches.  If avoiding changes
> in such situations is desireable, as I think it is, then extra process
> to discourage such changes would be good.

There is an ongoing debate within both the Python developers, and
the Python users, whether strict rejection of new features is a good
thing. I've personally come to the conclusion that I will bow to
whatever decision the release manager decides.


More information about the Python-Dev mailing list