• write draft of the Release Notes (look at the svn commits since the last release)
• inform mailing list
• gather patches
• fix critical open bugs
• make fix
• Enable all APPLICATION_LOCALES in application/showcase, temporarily. Make. Commit *.po files. Switch back to reduced set of locales.

• Sync README text file with About
• Prepare article in http://qooxdoo.org/news
• Prepare text for http://freshmeat.net (short; no marketing buzz)

$ tool/generator.py --migrate-source --migration-target 0.6.5 --class-path source/class/ --class-path ../application/apiviewer/source/class --class-path ../application/feedreader/source/class/ --class-path ../application/webmail/source/class/ --class-path ../application/skeleton/source/class/ --class-path ../application/showcase/source/class/ --migration-input ../application/sample/source/html/

$ cd $qooxdoo
$ svn update

$ cd $qooxdoo/frontend/framework/migration/

• Create a new directory “major.minor.revision”.
• Grep for deprecated tags in Code.
• Extract API changes from SVN diff to previous release.
• Add migration files and commit these to SVN.

Test of new migration data:

$ cd $qooxdoo/frontend/framework
$ tool/generator.py --class-path source/class --migrate-source --migration-target 0.6.4

• adjust svn:property qx:version auf trunk folder
• adjust version string in tool/data/config/[application.json|base.json]

$ cd $qooxdoo/frontend
$ make fix
$ cd $qooxdoo
$ svn commit -m "make fix"

$ cd $qooxdoo/frontend
$ make distclean
$ make source build release
$ cd $qooxdoo/backend
$ make release

• Build:
  • Unzip archive and open the demos.
  • Open the demos in different browsers.
• SDK
  • Unzip archive.
  • Compile a skeleton.
  • Do a make api in one of the examples

$ cd $sample
$ make source build api

Suppose the release you want to publish is 0.8-alpha1 and the software revision of that release was r13676. Then you could tag this release in SVN like so:

svn copy https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/trunk -r13676 \
  https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/tags/release_0_8-alpha1 \
  -m"tagging 0.8-alpha1 release"

• remove unstable code or code for future releases
• repeat the tests

$ cd $qooxdoo/frontend
$ make release
$ cd $qooxdoo/backend
$ make release

The following two steps can be performed in parallel, but you will have to complete the upload before you can complete the new release form.

• Files have to be uploaded to your individual upload directory. For a complete description see here. Here is a sample session using cadaver, a WebDAV client:
  • Connect to your upload directory (will prompt for your sourceforge.net user-id and password):

    cadaver  https://frs.sourceforge.net/t/th/thron7/uploads

  • Upload the files; files have to be placed into this directory directly, so don’t create subdirectories.

    put frontend/qooxdoo-0.8-alpha2-sdk.zip
    put frontend/qooxdoo-0.8-alpha2-build.zip
    put frontend/release/qooxdoo-0.8-alpha2-quickstart.zip
    put backend/release/qooxdoo-0.8-alpha2-backend.zip
    

  • Check result and quit:

    ls
    quit
    

A Sourceforge Release item has to be created, so it shows in the Download area of the project.

• Add a new release
  This online form will take you through several steps. Here are the most important items to enter:
  • Package: Final releases go into qooxdoo, pre-finals (alpha, beta, ...) go into qooxdoo-test
  • Name: The version of the new release (e.g. “0.8-beta1”)
  • Release Notes / Change Log: Enter the URL to the qooxdoo.org release notes (e.g. “http://qooxdoo.org/about/release_notes/0.8-beta1“) in the paste boxes for both fields
  • Submit (this is currently a mulit-form document and you have to submit at the end of each section)
  • Add Files: Files from your upload directory will show up here (i.e. the same user uploading the files has to go through this form) and have to be selected. If you do the upload now, refresh to update the file list. Once finished submit.
  • Edit Files: For each file you have to select a platform and a file type. Platform is usually “platform-independent”, file type “.zip” for pre-compiled packages (e.g. build, quickstart), “source .zip” for non-pre-compiled ones (sdk, backend). You have to submit each individual file.
  • Email Notification: Select “I’m sure” and send notifications.
  • Here are two older screenshots so you get a feeling for the form you go through:

Adjust version number of trunk to next version-pre

• change the svn:property qx:version of the qooxdoo/frontend folder
• change the QXVERSION macro in the qooxdoo/frontend/tool/data/config/application.json file

For at least the products forntend and tools (in fact, backend as well):

• Add current release version into product versions.
• Add next possible release version into milestones.

• Adjust the roadmap.

• Release notes on the homepage
• Upload demos to the homepage
• News
• Mailing list (qooxdoo-devel)
• Freshmeat
• Wikipedia version number update
• Email to Ajaxian?!