[bt-devel] Your changes in CVS

[Greg Hellings]

On Tue, Nov 17, 2009 at 4:38 PM, k486 <k486 at digizip.com> wrote:
> * Raoul Snyman <raoul.snyman at saturnlaboratories.co.za> wrote on [2009/11/17 03:18]:
>> On Tue, 17 Nov 2009 11:08:03 +0200 (EET), Eeli Kaikkonen wrote:
>> > BTW, if the long time waiting for final realease is a problem, maybe we
>> > could create a new 2.x branch before beta or rc? Then the head would be
>> > open to larger changes.
>>
>> I'd recommend that beta release becomes a code freeze, we branch then, and
>> only bug fixes happen in that branch. Once final is released, we can merge
>> those bug fixes back into trunk. This branching technique will allow
>> greater freedom in trunk, and less problems. Of course our tagging of
>> releases happens in conjunction with this.
>
> Hi all!
>
> I'm slightly confused about the roles of the trunk and branches.  Is it
> not the norm for trunk or the mainline to remain as stable as possible
> and for major code changes and new features to be tracked in development
> branches?  Then after everyone has tested and reviewed the development
> code, it is merged back to the trunk.

We do most development in trunk on HEAD.  We create a branch at the
time of release of a new minor version (or maybe at the time of the
first RC for it, I don't remember off-hand).  We then leave that
branch for sub-minor version increments, which are restricted to bug
fixes.  Bug fixes usually go into Trunk and, if the person who is
fixing it deems it worth the time and effort, they might port it back
to one of the latest minor version branches also.

So with 2.4 final being expected today, a 2.4 branch would be created.
 Then HEAD is open for further development until the RC for 2.5 is
announced.  Then we try to keep HEAD stable for the few weeks that we
are in RC.  At any time, minor fixes may be applied to 2.4 and, if
enough are discovered that it is deemed worthwhile, we will make a
2.4.1 release, followed by 2.4.2, 2.4.3, etc.

--Greg

>
> I'm new so I don't want to make any assumptions or presumptions for that
> matter.
>
> Kang
>
> PS - Thomas, thanks for the warm welcome!
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>