Merging to the release_1_6 branch

Rainer Müller raimue at
Tue May 27 12:48:25 PDT 2008

Jordan K. Hubbard wrote:
> 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.

If we would do this the way you describe, every new feature would have 
to be developed on a different branch. It could just be merged in as we 
prepare a new major release. This is absolutely not practical, as nobody 
would test new code/features and it would create even more branches 
which need merging. Also, this approach need to do code freezes which 
would make development on this project even more slow than it currently is.

There is unfinished stuff on trunk at the moment which I would not want 
to appear in a release, because it is not ready for public consumption. 
For example registry2.0 (okay, we already included that... why?) and the 
half-baked implementation of 'port help'.


More information about the macports-dev mailing list