A number of artifacts are produced as part of making an X10 release.
The main artifacts are:

  1. Binary releases of the PGAS runtime (hosted on codehaus) for each supported OS/hardware target.
  2. A source release of X10.
  3. A source release of the X10 test suite.
  4. Binary platform-independent release of the Java backend and runtime.
  5. Binary platform-dependent releases that contain both the Java and C++ backend and runtimes for each supported OS/hardware target.
  6. PDF of the X10 language specification

The following is the procedure used to make a release of X10.

Before creating the release branch (typically the day before)

  1. Update the version information in x10.compiler/src/x10/Version.java
  2. Update the plugin manifest version in all MANIFEST.MF files in X10 core projects
  3. Copy the current set of PGAS binaries found in the svn head sub dir of http://dist.codehaus.org/x10/binaryReleases/ to a new subdirectory named with the release number and change x10.runtime/src-cpp/x10rt/pgas/pgas.mk to pull from the release directory. The easiest way to move the files around is with cadaver (a command line tool with similar interface to sftp).
    mkdir junk
cadaver https://dav.codehaus.org/dist/x10/binaryReleases/svn%20head
<login>
mget *timestamp*
cd ../<release-dir>
mput *timestamp*

Create the release branch and enter into final testing phase

  1. "Tag" the release by using x10.dist/releng/makeTag.sh Use a svn revision number that matches one reported by a night-sanity run. i.e.
    makeTag -rev 12500 -tag SF_RELEASE_2_0_1
  2. Enable the release-branch regression testing on triloka21 and 23. Log in as x10reg to each machine, update scripts to pull from the release branch created by makeTag, and uncomment crontab entry.
  3. If fixes need to be applied to the release after it is created, apply fixes to head first. After they pass regression testing on head, pull them over to the release branch using
      svn merge -c <change revision> ^/trunk

When all necessary fixes have been propagated to the release branch, one can build the actual release artifacts:

  1. Update JIRA version management to indicate that version has been released.
  2. Edit and commit release notes to the trunk. Release notes can be mostly generated from JIRA. Use svn merge to get the release notes from the trunk to the release branch.
  3. One each target platform, run the x10.dist/releng/buildRelease.sh script.
    buildRelease.sh -version 2.0.1 -tag SF_RELEASE_2_0_1

    This will create the three platform independent zip files and the platform-specific tar ball.

  4. ssh into shell.sf.net and create a subdirectory of /home/frs/project/x/x1/x10 to hold the downloads. Use sftp to put them there as they are produced by buildRelease.sh on each platform. NOTE: AIX takes a very long time to build with optimization.
  5. Put language spec pdf on dist.codehaus. Update in place x10-latest.pdf in addition to creating a x10-<version>.pdf. The release page itself will point to the x10-<version>.pdf. All of the other parts of the website refer to x10-latest.pdf.
  6. Generate new x10doc and upload it to dist.codehaus
  7. Update the confluence "X10 Releases" page to link to the new download version.
  8. Send out mail announcements to x10-users and x10-announce
  9. Also post announcement in SF news and Confluence news.