Policy RFC: branches/2.0 change process
c.shoemaker at cox.net
Wed Jul 12 22:47:55 EDT 2006
On Thu, Jul 13, 2006 at 11:40:55AM +1000, Conrad Canterford wrote:
> On Wed, 2006-07-12 at 20:26 -0400, Chris Shoemaker wrote:
> > On Wed, Jul 12, 2006 at 07:33:55PM -0400, Derek Atkins wrote:
> > > Then how do we get a proposed change audited before it's commited to
> > > the 2.0 branch?
> Would a 2.0-testing branch solve this issue? We keep a pristine, tested
> and approved 2.0 branch, and also have a testing branch where people can
> commit stuff for others to verify/approve. Gets around the problem of
> "head" code diverging from 2.0 (especially with register rewrites a
> possible mooted change I think this could be an issue). I'm assuming
> that its not too hard to pull changes between branches....?
> I must admit I'm not too familiar with how svn differs from cvs, so this
> may not be practical with svn...
It's practical, and I'm fine with that approach, with one constraint:
That we allow changes to the 2.0 branch _only_ in the form of
contiguous merges from the 2.0-testing branch. This ensures that
every state of the 2.0 branch must be exactly equal to some state in
the 2.0-testing branch. That implies no cherry-picking.
More information about the gnucash-devel