[Bf-committers] Roadmap for 2.5x - 2.6x - beyond

[Reuben Martin]

On Sun, Mar 13, 2011 at 9:52 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> 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