sounds great. This is more-or-less what we do with CVS in my shop. Eric
> -----Original Message----- > From: Eugene Gluzberg [mailto:[EMAIL PROTECTED]] > 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" <[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/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:[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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
