On Sun, Mar 13, 2011 at 9:52 AM, Brecht Van Lommel <[email protected]> wrote:
> There is the issue of how to do such a release schedule in terms of > branches. Most power users are simply using trunk and not releases, so > having separate branches for development and stable releases is not a > viable option in my opinion. I propose to center everything around > trunk, and let developers use short lived branches while trunk is > locked if they want to. > > If we keep the release cycle sufficiently short, developers know they > can merge things soon. I think we should try to avoid branches that > live too long. Features don't get good testing, it's demotivating for > developers, and merging them destabilizes trunk too much. Just split > up things if it doesn't fit the release schedule. > > Existing major branches should be merged in pieces if they risk > destabilizing things too much. If code can't be stabilized in a few > weeks, it simply should not go in trunk, in my experience it is always > possible to split things up. > I don't know if this has already been discussed or not, but has anybody looked into moving to a git based system? From what I understand, it makes it much easier for developers to track and keep their development branches in sync with the tip of the main development trunk. It seems that often the development branches get way out of sync with trunk, and then that often becomes a major obstacle to merging them. Git seems to make the managing of branches a much more trivial operation. I would present several hurdles though. Time require to move from svn, completely different code management paradigm, and possible issues for windows developers. (Not sure if that last one is still an issue any more...) But from observing other projects, it does seem to lend some real advantages to a quick development cycle with many development branches. -Reuben _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
