I think I agree with Jan. At this point in the project, while the
code is still young, most work should go into the trunk. I think the
trunk should be in working condition, but considered unstable for
deployment. To keep things moving forward, most new code should go
into the trunk.
Therefore branches will be created when we want a stable code stream
(releases), or when we are working on disruptive changes (ex.
mochiweb), but generally all new work should go into the trunk.
Later in the project, as project and code base and contributors get
bigger, we may need to switch to a more structured system, but for
now I think a single, slightly unstable trunk with occasional
branches is the most efficient way.
-Damien
On Feb 29, 2008, at 9:06 AM, Jan Lehnardt wrote:
Heya,
On Feb 29, 2008, at 13:53, Noah Slater wrote:
Toughts, comments, ridicule? All welcome. ;)
Let's not do that :)
Having trunk representing the latest release only seems
to me as arbitrarily diverting from the route people are
used to: Trunk is where development happens and where
it can be messy. Stable branches are where people can go
an pick stable releases if trunk is unusable for the moment.
Which I hope doesn't happen too often, but still.
Experimental work, like the mochiweb, should still happen
in separate branches. Releases get their on branches for
maintenance.
Your argument that ChangeLog remains clean assumes that
we have automatic ChangeLog generation. This is fine per se,
but a little change to the mechanism would solve the problem
of ChangeLog pollution.
The automatic generation would take SVN commit messages
and put them into the ChangeLog automatically. If we do a lot
of minor changes and reverts and whatnot, the ChangeLog
grows unnecessarily and contains entries of little value.
Instead of copying every message, our automaton could look
for opt-out tags in the message. For example a message
prepended with a "!" (Bang) denominates a small change,
like a revert, and ignores it for the creation of The ChangeLog.
If the opt-out tag is forgotten, we still end up with too many
entries, but we can go through the ChangeLog before a
release. We might do that anyway for preparing a release
announcement.
Cheers
Jan
--
