Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 82122 invoked from network); 15 Apr 2002 16:11:48 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Apr 2002 16:11:48 -0000 Received: (qmail 11428 invoked by uid 97); 15 Apr 2002 16:11:50 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 11412 invoked by uid 97); 15 Apr 2002 16:11:49 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 11390 invoked from network); 15 Apr 2002 16:11:49 -0000 Errors-To: User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 15 Apr 2002 09:11:42 -0700 Subject: Re: Building a release From: Peter Carlson To: Lucene Developers List Message-ID: In-Reply-To: <01fc01c1e493$1fbf22f0$9e01110a@realpulse.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Looks like a good thing to do. Thanks for bringing it up. --Peter On 4/15/02 8:35 AM, "Eugene Gluzberg" wrote: > I would like to suggest we use branches for all future releases after this > one. > > Doing branches will allow us to continue development on new features when > nessesary while keeping a code freeze on the branch. > > Most people fear branches because of conflicts. However I recently > discovered a way of preventing unessesary conflicts by using some extra > tags. > > I had recently read some of the chapters in a book called "Open Source > Development with CVS" by Kark Fogel, and found some really good ways of > managing releases and branches, etc. > > For instance whenever we would do a code freeze for a release we would: > > 1. create a tag in the code: > cvs tag start_1_3 > 2. create a branch in the same place: > cvs tag -b branch_1_3 > 3. continue new feature development on the trunk and fix bugs related to > releases on the branch > Whenever we need to merge the fixes from the branch to the trunch we would > do the following: > 1. On the branch: > cvs tag merge_1_3-1 > 2. on the trunk: > cvs update -j start_1_3 -j branch_1_3 > then check that the merge went ok and commit. > > Next time we do a merge from the branch to the trunk we would: > 1. on the branch > cvs tag merge_1_3-2 > 2. on the trunk: > cvs update -j merge_1_3-1 -j branch_1_3 > check that the merge went ok and commit. > > I did not know how to use the double tag merge until recently, which saved > my ass from fixing conflicts all the time! > > What do you guys think? -- To unsubscribe, e-mail: For additional commands, e-mail: