river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: [RESULT] [VOTE] Accept the Service UI Specification document from Artima, Inc.
Date Fri, 09 Nov 2007 17:25:38 GMT
Jim Hurley wrote:

> If folks think that is needed or would be helpful to figure out other
> svn management issues - that's cool.  I'm not the right person to lead
> that discussion, so (if it's important) someone should grab the ball
> and get it started...

I don't believe it is necessary to draft guidelines with regard to
branching at this stage, having said that ...

I agree the trunk is the right place for committing code for which
committers believe there is consensus for receiving that fix/feature.
Experimental stuff can be done in an experimental branch if coordination
is required between various people or when committers want to show that
code to the world, otherwise their IMO ones own sandbox is just fine.
Proper IDEs have local version control as well, or you can use one of
the many available version control systems.

Subversion is rather weak with regard to integrating changes between
various branches so it is wise to branch only when things have really
stabilized, or we should use a different version control system that
keeps track of the integration history. Not that integrating changes
from one branch to another will ever become easy when time elapses ;-)

When a different policy becomes effective for a certain codebase it is
wise to branch, such as with the stabilizing phase when the feature set
for a new release has been (almost) completed.

That brings me to my most important point, what is withholding us from
branching the current trunk into a release X and we start with the next
phase where people can work on what they want to work on.

View raw message