couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Repository procedure proposal
Date Fri, 29 Feb 2008 16:47:23 GMT
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.


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
> --

View raw message