Jukka Zitting wrote:
Hi,
On Dec 21, 2007 1:46 PM, Mark Brouwer <[EMAIL PROTECTED]> 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
