lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Friedman, Eric" <e...@ConveySoftware.com>
Subject RE: Building a release
Date Mon, 15 Apr 2002 17:38:13 GMT
sounds great.  This is more-or-less what we do with CVS in my shop.

Eric

> -----Original Message-----
> From: Eugene Gluzberg [mailto:drag0n2@yahoo.com]
> Sent: Monday, April 15, 2002 8:35 AM
> To: Lucene Developers List
> Subject: Re: Building a release
> 
> 
> 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?
> 
> ----- Original Message -----
> From: "Jason van Zyl" <jvanzyl@zenplex.com>
> To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
> Sent: Friday, April 12, 2002 11:34 AM
> Subject: RE: Building a release
> 
> 
> > On Thu, 2002-04-11 at 19:02, apache@lucene.com wrote:
> > > I had a chance to update these instructions a bit today.  
> I have not
> tested
> > > them, but now I think the naming conventions are all 
> correct, and I
> added
> > > some steps about updating the web site and javadocs.  
> These document
> (more
> > > or less) what I've done for each of the 'rc' releases.
> >
> > You guys might be interested in Maven. This is exactly the kind of
> > development process stuff that Maven attempts to make easier.
> >
> > We are using Maven for all the Turbine stuff, Jetspeed is 
> using it, a
> > few of the commons components, 14 projects @ DARPA, ObjectBridge @
> > sourceforge is moving toward using Maven and it looks like the
> > CheckStyle author is interested.
> >
> > http://jakarta.apache.org/turbine/maven/
> >
> > I would be glad to help out if you wanted to try it. A 
> mavenized build
> > co-exists with any existing build system so you can try 
> before you buy
> > and dump it if you don't like it.
> >
> > > Doug
> > >
> > >
> > > ----
> > >
> >
> > > Following are the steps to perform a lucene release.
> > >
> > > These assume that you have the appropriate privledges.  These also
> > > assume that the time is right to perform such a release, 
> and that you
> > > know the name of the release you'll be making.
> > >
> > > Note that release versions are formatted slightly differently in
> > > different places, e.g., dashes are used in file names, 
> underscores are
> > > used in CVS tags, and dots in directory names.  The examples
> > > illustrate these differences.  These naming differences may seem
> > > random, but they are the conventions used, and in some 
> cases (e.g.,
> > > CVS tags) they are required.
> > >
> > >  1. Update the CHANGES.txt file.
> > >
> > >     Check the email archives, and make sure that there's 
> an entry in
> > >     this file for every significant CVS commit message.
> > >
> > >  2. Update default.properties so that the version 
> property names the
> > >     next release (one beyond the one currently being 
> built) with -dev
> > >     appended.  So if you're making release 1.2rc5, then 
> the version
> > >     property should default to 1.2-rc6-dev.
> > >
> > >  3. Commit these changes.
> > >
> > >  4. Start with a clean CVS tree.  The surest way to do this is to
> > >     check out a new copy from CVS, with the command:
> > >
> > >       cvs -d :ext:$USER@cvs.apache.org:/home/cvs co jakarta-lucene
> > >
> > >     If you don't do this, at least do:
> > >
> > >       ant clean
> > >       cvs update -d
> > >
> > >     The latter should confirm that everything is up to 
> date, and that
> > >     you don't have any extraneous files lying around.
> > >
> > >  5. Build the release with a command like:
> > >
> > >        ant -Dversion=1.2-rc5 dist dist-src
> > >
> > >     (The version here should be formatted as in 
> default.properties.)
> > >
> > >  6. Examine the results.  Did it build without errors?  Unpack the
> > >     release somewhere, examine the files, run some simple 
> tests.  Do
> > >     not proceed further until you are confident that this 
> release is
> > >     of appropriate quality.
> > >
> > >  7. Tag the files in CVS with the release name.
> > >
> > >     The release is tagged with a command like:
> > >
> > >        cvs tag lucene_1_2_rc4
> > >
> > >     (Note the use of underscores instead of dots or dashes.)
> > >
> > >  8. Make a new release directory on www.apache.org.
> > >
> > >        ssh www.apache.org
> > >        mkdir
> /www/jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc5
> > >
> > >      (Note that the version is here prefixed with a 'v'.)
> > >
> > >  9. Copy the files to the release directory:
> > >
> > >   scp *.gz *.zip
> www.apache.org:/www/jakarta.apache.org/builds/jakarta-lucene/r
elease/v1.2-rc
5
> >
> > 10. Update the website.
> >
> >   ssh www.apache.org
> >   cd /www/jakarta.apache.org/lucene
> >   cvs update
> >
> > 11. Update the javadoc on the website.
> >
> >     This is done by unpacking it from the release that you've just
> >     made, moving it into place, then deleting the old version.
> >
> >   ssh www.apache.org
> >   cd /www/jakarta.apache.org/lucene/docs
> >   tar xzf
../../builds/jakarta-lucene/release/v1.2-rc5/lucene-1.2-rc5-tar.gz
lucene-1.2-rc5/docs/api
> >   mv api api.old ; mv lucene-1.2-rc5/docs/api api
> >   rm -rf api.old lucene-1.2-rc5
> >
> > 12. Start a new, empty section in CHANGES.txt for the next release.
> >
> >
> > Much of this could probably become a shell script.
> >
> > Doug
> >
> > ----
> >
>
> > --
> > To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
> http://tambora.zenplex.org
>
>
> --
> To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message