Merging to the release_1_6 branch

Rainer Müller raimue at
Tue May 27 15:50:15 PDT 2008

Caspar Florian Ebeling wrote:
> Yeah, and that's the whole problem. With svn you dump all your new half-cooked,
> half-done features into trunk. With Git it's the reverse situation.
> You do the dangerous
> things in branches and can assume that mainline is reasonably in shape. That's
> only a tendency. But I know from exprience why I don't want to release things
> from trunk under svn usually. And if only complete, well-understood
> features would go
> into it, I would feel different. It's a bit like not comitting with
> subversion for 10
> days, but having everything in the undo history, or something.

Now you are talking about feature branches here, while I was referring 
to release branches in my statement before.

> Of course you would have it tested by a broader audience, after merged to
> master. And you would sync releases so that you have a grace period for that.
> But you don't run trunk all the time, with half-feature A, 3/4 of B and
> all of C, but only C. And then all of B, when it's author is happy. Etc. That
> does not solve eberything, but it's better.

I agree with you here that feature branches should only be merged then 
they are considered to be complete by the author(s) of this feature.

But now we are in the discussion about feature branches while I 
initially started to talk about release branches. Let's stick to release 
branches as it is more important for now to get a 1.6.1 release.


More information about the macports-dev mailing list