Differences between revisions 11 and 12

Deletions are marked like this. Additions are marked like this.
Line 64: Line 64:
 * Do a clean export with {{{cvs -d:pserver:anoncvs@cvs.savannah.gnu.org:/cvsroot/classpath export -r <releasetag> classpath}}}  * Do a clean export with {{{cvs -d:pserver:anoncvs@cvs.savannah.gnu.org:/cvsroot/classpath export -r classpath-0_<releasenumber>-release classpath}}}

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.

Build Testing

  • 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.

Smoke Testing

  • 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.

Regression Testing

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).


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.

Final changes

  • 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:anoncvs@cvs.savannah.gnu.org:/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:
    1. gpg -b classpath-0.<releasenumber>.tar.gz

    2. create a directive file classpath-0.<releasenumber>.tar.gz.directive

    3. gpg --clearsign classpath-0.<releasenumber>.tar.gz.directive

    4. connect to ftp-upload.gnu.org and cd to /incoming/ftp
    5. upload classpath-0.<releasenumber>.tar.gz, classpath-0.<releasenumber>.tar.gz.sig and classpath-0.<releasenumber>.tar.gz.directive.asc

    6. 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



  • Add the new release number to Bugzilla for the 'Reported against' field and the new future release number for the 'Target' field

ClasspathReleaseProcess (last edited 2009-02-05 23:51:59 by AndrewHughes)