Merging to the release_1_6 branch (was: Re: Fwd:

Caspar Florian Ebeling febeling at
Tue May 27 12:47:47 PDT 2008

> This is why I think that releases should be tags on trunk, with a
> convergence period before each release.  This project is not big
> enough and does not have the manpower or written guidelines and a
> release engineer driving the process on a daily basis which are
> necessary to really do a two-branch model.  That is merely my opinion,
> of course, but it's driven by some experience in this area.

This is exactly what I have been preaching, but I think it changes
with Git. I know that saying this might well be boring by now, but Git
eases the whole branch handling a lot. And is really
not a substitute here. I used it for a feature branch of a project and
some file renamings made things go haywire. It was certainly not
the reassurement your actually want to get out of version control.

But git mostly makes branches a private thing, so that effectively
their number rather gets reduced, or at least the number of public
ones gets reduced. The existing branches tend to be feature-specific,
and mainline
stays sane because branches only get merged in once they are
not questionable anymore.


Florian Ebeling
florian.ebeling at

Florian Ebeling
florian.ebeling at

More information about the macports-dev mailing list