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" <[EMAIL PROTECTED]>
To: "Lucene Developers List" <[EMAIL PROTECTED]>
Sent: Friday, April 12, 2002 11:34 AM
Subject: RE: Building a release
> On Thu, 2002-04-11 at 19:02, [EMAIL PROTECTED] 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:$[EMAIL PROTECTED]:/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/release/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:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
> http://tambora.zenplex.org
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
