Creating a new GNU Classpath developer release snapshot.
Before starting on any release make sure at least the basic testing give OK results. After starting with the release branch you will have to do everything twice (head and release-branch). So don't create the branch too early.
- Make sure you got at least one runtime which can be used the "out of box". Go through NEWS runtime/platform changes list. Submit patches to runtimes when necessary.
Make sure make distcheck passes (already done by builder.classpath.org)
Try a couple of different configure options --with-javac and --with-ecj (done by builder.classpath.org), --enable-regen-headers (try a rm include/java_*.h include/gnu_*.h and compare results with CVS version), --enable-Werror (should work on GNU/Linux systems, but cygwin for example has some problems still), --enable-gtk-cairo, etc.
- Go through the GNU Classpath Examples and make sure they look OK.
Try at least couple of programs from FreeAWTTestApps and FreeSwingTestApps (also try --enable-gtk-cairo and -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D with something like jedit just to see if Graphics2D isn't completely broken).
Do a full "bootstrap" using eclipse following the ClasspathHackingWithEclipse instructions. Running with the just build classpath (e.g. PATH=.:/usr/local/jamvm/bin:$PATH ./eclipse -vm jamvm -debug -consoleLog -vmargs -Xmx750M), install the CDT through the plugin manager then checking out and building classpath again from CVS gives a good feeling how stable things are. For bonus points try the help pages which uses tomcat and jsp pages.
The autobuilder and regression tester on builder.classpath.org should have caught most issues, but it unfortunately does miss some things from time to time (hopefully the new Mauve framework from Tony will help here). So for now you need to install a <releasenumber>-1 first and run batch_run | tee old-results on it in mauve, then do that again against a CVS head version. Just diff -u old-results new-results and go through the changes to see if there are any regressions (search for ^+FAIL or ^-PASS to see if there are any suspicious entries).
Some programs come with regression suites themselves. If there is time it is a good idea to try a few like the jfree testsuite (that one is also a nice ant build and free swing test).
- Report any issues from the smoke or regression testing.
Go through all open bug using http://www.gnu.org/software/classpath/bugs.html and decide if there are any which are too embarrassing to release with.
While going through the bugs make sure that closed bugs have the correct target release set so http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.<releasenumber> gives all things fixed for this release.
- Post a list of issues to the mailinglist asking for others to take a look when necessary.
Creating release branch
If the results of testing and the list of remaining bugs is manageable then start creating the release branch.
- Make sure you have a clean checkout of CVS head.
Mark the point where the branch was made: cvs tag classpath-0_<releasenumber>-branch-point
Create the release branch: cvs tag -b classpath-0_<releasenumber>-branch
Update version number (only on the head!) in configure.ac to 0.<releasenumber>+1-pre
Make sure you have clearly marked your HEAD and release-branch working directories so you won't accidentally commit something to the wrong one.
Retesting and Last minute changes
- Go through the list of must fix bugs and fix them.
All bug fixes should now be done in 2 places:
- On head (everybody can do this) - people should CC the release manager if a bug fix is important for the release.
- On the release branch (only the release manager should do this).
- Do all testing again, but with more detail (hope you won't find any new major now show stoppers...)
When there are no embarrassing bugs left we can start the actual release process.
- Date in NEWS file
- version in configure.ac
Do one final make distcheck
Mark the branch cvs tag classpath-0_<releasenumber>-release
Do a clean export with cvs -d:pserver:email@example.com:/cvsroot/classpath export -r classpath-0_<releasenumber>-release classpath
cd classpath; ./autogen.sh && ./configure && make distcheck which should give you a clean classpath-0.<releasenumber>.tar.gz
Follow the instructions at http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Procedure.html
- Basically this involves:
gpg -b classpath-0.<releasenumber>.tar.gz
create a directive file classpath-0.<releasenumber>.tar.gz.directive
gpg --clearsign classpath-0.<releasenumber>.tar.gz.directive
- connect to ftp-upload.gnu.org and cd to /incoming/ftp
upload classpath-0.<releasenumber>.tar.gz, classpath-0.<releasenumber>.tar.gz.sig and classpath-0.<releasenumber>.tar.gz.directive.asc
disconnect and wait for the file to appear in ftp://ftp.gnu.org/software/classpath or for an e-mail if it went wrong...
The directive should look like:
version: 1.1 directory: classpath filename: classpath-<releasenumber>.tar.gz
- Write release announcement.
Send release announcement to mailinglist and firstname.lastname@example.org
Update Free Software Directory
Optionally sent email to email@example.com, submit to freshmeat, osnews, etc.
- Add the new release number to Bugzilla for the 'Reported against' field and the new future release number for the 'Target' field