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
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