[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.
Regards,
Martin
More information about the Python-Dev
mailing list