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: Branching strategy (Was: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html)
Date Fri, 21 Dec 2007 12:53:21 GMT
Jukka Zitting wrote:
> Hi,
> 
> On Dec 21, 2007 1:46 PM, Mark Brouwer <mark.brouwer@cheiron.org> wrote:
>> Jukka Zitting wrote:
>>> My advice is not to use "development branches" if there's any way to
>>> avoid them. Each such branch is essentially a fork of the project.
>> My experience is that how to implement a feature is often not that
>> obvious in the first place, also implementing such a feature could be a
>> cooperative development between a subset of committers that might have
>> lots of side effects and can take a long time span to materialize before
>> it can be decided whether the trunk should receive it.
> 
> I would classify it as a major architectural defect if there is a
> frequent need for features that can't be split to smaller steps, have
> lots of side effects, and require lots of effort implement.
> 
> Apart from major architectural redesigns any new features should
> generally only affect one or just a few components within a project.
> Even for central API changes it should be possible to come up with an
> incremental upgrade path where existing components can keep using the
> previous API until they get upgraded.
> 
> Instead of branching the whole project, it would IMHO be much better
> to use a sandbox of experimental components that should remain
> compatible with the trunk. Such components might be forked versions of
> "stable" components in trunk, but even for such cases I'd rather see
> the shared code being refactored to a base component that both the
> "stable" trunk version and the experimental snapshot component extend.

No denial here (I think). The proposal mentions the /trunk as the main
line of development, /maintenance when we are feature ready for a
release (to provide support for releases) and the /tags for the actual
releases.

The /branches branch kept for any branch to be found necessary, reasons
for branching can be many and probably hard to capture under one policy.
I called it therefore adhoc (dunno whether that is the best word), in
case there is a possibility to achieve the same result with less
troubles I'm in for that, if not and we need to branch I would like to
see that branch in the /branches branch and not being mixed up with the
/maintenance branch because for that we have a uniform policy.

BTW as I noticed there was not much participation of others related to
this subject, do we need to bring this up for an official vote?
-- 
Mark

Mime
View raw message