Martin v. Löwis wrote: > 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. ... > 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. Well, I never backport 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. Then we disagree strongly about what should happen. I don't see any point in a feature freeze if you are going to then change features. ;) IMO, it is really bad to make feature changes after a beta release or in bug-fix releases. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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