Ross Gardler wrote:
...
Once we have an RC built we only allow bug fixes in trunk, new features
are developer in a branch.
I wouldn't be that strong. If I'm adding a new feature to the trunk, but
this does not interfere with prior behaviour, there are no problems.
It's just about keeping the trunk possibly bug-free, as far as the
developer is concerned.
If we use branches for all new features, we have the problem that nobody
will check what is happening, like with views. We should really push for
small reversible changes in the trunk, and use branches only when this
is not possible (like in a new feature that needs core refactoring).
Smaller changes are more easily testable, reversible, and auditable by
all. Big commits tend to go by without peer review.
Subsequent RC's for that release should be
made every couple of weeks. Once we have a couple of weeks with no bug
fixes we release.
Remember that plugins can have a separate release cycle. So only work on
core need move to a branch.
Yup, that's cool :-)
Furthremore, these branches should merge whenever possible between them
in a single branch so that they can be coded together, and get merged
with the trunk only when all developer-known bugs are fixed.
I understand that there will inevitably be dependencies between
branches but I don't care for merging branches into a single branch
(btw, wouldn't that ultimately become the defacto dev trunk?).
There should not be dependencies between branches. If there is, then
it should merge in a single branch.
But this will prevent complete features being merged with trunk because
incomplete features are brought into the branch. All that will happen
there is that the branch will get into the state that trunk was in
before the 0.7 release and we will split our devs between creating new
features in the branch and maintaining trunk (not necessarily a bad
thing, but do we have enough devs for this?)
We should not get into a situation in which an incomplete feature merges
with a more complete branch. This happens when development is too long,
and people start using the branch as their trunk.
If this is not possible, it's the most incomplete feature that must
incorporate the changes from the more complete one, not the opposite.
This frees it from being stopped in merging with the trunk.
...
In other words, I am +1 for an "always RC quality" or an "always beta
quality" (as Nicola said in another reply) trunk. I am also +1 for
"alpha" quality branches where necessary.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
