*** Introduction *** This document describes how to do a flexdock release. It assumes the following things: - versioned releases are done off of the HEAD of the trunk branch of the project in CVS - there is an effective project freeze during the time of the release where no one except those doing the release commit onto the trunk branch - all future development work is located on branches and will be merged to trunk after the release is performed - if a problem is found shortly after the release, and future release work has already been merged to trunk, a ..release (e.g. will be done by creating a .. release branch, repeating the release with the new .. version number relative to that specific branch and once the files are released to the server, merging the ..release fixes to the trunk branch. This may change in the future, but is a very simple release management approach for the time being. *** About Native Code *** Currently, native code for a flexdock build is checked into the project. For the time being we will trust that committers of C code check in updated linux-x86 and windows libraries when changing the C code. Therefore, a releaser does not need to figure out how to build native code. In the future we will add checks to the build process to ensure that the commit timestamps of the native code libraries are newer. This will help us detect the obvious case where someone updates the C code without updating the native code library *** Diffing dirtrees/zips *** The instructions below call for diffing of directory trees and/or zips. You cannot just use diff to do this as you will need something that can recurse into zip/jar archives. If you are release on Windows, then consider using BeyondCompare (it's got a try/buy license). I'm not sure what UNIX tools are available yet, but will research to make ensure there's no reason not to follow the directions below on UNIX system. *** Instructions for Performing a Release *** If at any point you run into problems and have to change code to do the release, restart at the first step (or at least make sure that all code is committed back to HEAD in the clean working copy you create in step 1). We want this to be repeatable. Note: the files located in the www directory are used by java.net to display the flexdock home page. Since the contents of these pages are dependent upon the release, these files will NOT be updated until after the new flexdock version are archived on the web site. 1) Create a clean CVS working copy from HEAD of trunk branch 2) Ensure that "version" property in build.xml is matches that for the upcomping release. If it does not, a) update build.xml to specify the proper version number in the "version" property b) test that you haven't broken the build.xml by doing a build and noting that the generated artifacts use the new version number in their file names c) commit the build.xml with the updated version number to CVS 3) Test that you can run: a) ant clean b) ant dist and that the build dir contains: flexdock-[version].jar flexdock-[version]-src.zip dist/flexdock-[version].zip dist/flexdock-demo-[version].jar 4) Verify that the demo app runs and reports the correct version. To do this run: java -jar build/flexdoc-demo-[version].jar 5) Verify that the src.zip can be used to produce the same output as a build from CVS. Instructions a) make a new dir b) cd to that dir c) expand flexdock-[version]-src.zip from the CVS build/dist dir d) run 'ant dist' from the exp e) run a recursive differ on that dir and the CVS dir ignoring timestamps and CVS dirs. Verify that there are no differences 6) Tag the release. To do this, you can tag the remote trunk branch or the working copy (assuming that the working copy is representative of trunk HEAD, i.e. if you had to change anything else, you've committed it). The format of the tag should be: flexdock_[major]_[minor]_[patch]. For example flexdock_0_4_0. To tag the from the working copy cvs tag [versiontag] for example cvs tag flexdock_0_4_0 * This'll probably be replaced with some ant targets later on ** the tag scheme is pretty simple now and will probably be enhanced when we start doing dailies/weeklies and/or preview releases 7) Create a clean CVS working copy from the tag created in the previous step 8) in that working copy run a) ant clean b) ant dist 9) diff the dist dir contents ignoring timestamps of the files and entries of the zips and jars in this working copy's build/dist dir to the build/dist dir of the working copy where you performed the tag two steps ago. 10) if #9 shows they are the same, then release the files a) Log into flexdock.dev.java.net b) Go to the "Documents & files" section of the project c) Select "Add new file" d) From the CVS versioned working copy add the file build/dist/flexdock-[version].zip (NOT THE JAR): i) Specify as the file name the same name as the file in the working copy (without the path) ii) As a description put "FlexDock [version] Binary Release" (substituting the right version number of course) iii) Select the zip file from the working copy via "Browse" button next to the "Attachment" radio button in the "Contents" section e) repeat c&d for the build/dist/flexdock-[version]-src.zip file, but use the description "FlexDock [version] Source Release" 11) Update the index.html file, the web start JNLP file, as necessary and copy the flexdock versions into the www area with: a) ant webstartapp