My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
ReleasingVersions  
How to use Ant to release the software
Featured
Updated Dec 12, 2010 by darren.pearce

Introduction

This page explains how to release the project software. It only applies if you are a member of the project. The following instructions assume that you are familiar with the terminology of Ant tasks and that you are using Eclipse.

Release Policy

Software should always be released when it is used for demonstration to people other than project members. It is often very useful for us to demonstrate buggy versions. In such cases, it is not necessary to add the release to the downloads section of this site. However, the software should still be jarred up rather than executed straight out of Eclipse. The reason for this is that by jarring up the software, the release mechanism in place ensures that all local changes are committed, thus ensuring that should it be necessary, we are able to revert to the exact version of the software that was used.

Prerequisites

The release mechanism uses the current Subversion revision number. In order to do this, you must have subversion installed locally. Note that this is different to installing Subclipse, the Subversion Eclipse plugin.

Releasing from the trunk

Typically we have released the software from the trunk of the repository. In order to do this, do the following:

  1. Open the Ant View in Eclipse (Window-->Show View-->Ant).
  2. Click with the right button in the window that then opens.
  3. Select 'Add Buildfiles'.
  4. Navigate to your MiGen Java project and select the file 'build.xml'.
  5. You should then see your project added to the view. Expand this by double-clicking or clicking on the expand 'triangle'.
  6. Double click on the target 'migensystem-zip'
  7. This will invoke the code that releases the software.

This may fail for a number of reasons, all of which you should pay close attention to and not ignore.

  • You don't have subversion installed so it can't be accessed on the command-line. The Ant targets that release the software need to use this. Please install it and try again.
  • You have local modifications to your working copy, i.e. uncommitted changes. This will be indicated to you by a subversion revision of something like 1559M where the M stands for 'modified'. You can fix this by committing these local changes or reverting to the original revision's files (1559's in this case).
  • Your working copy is not completely up-to-date. This can occur even when you have no local modifications yet some of your files can be from a range of revisions. Subversion version numbers indicate this using a 'colon' syntax such as 1551:1559. To fix this, do an update (Team-->Update).
  • A combination of both local modifications and revision 'spans'. This will be indicated by using the 'M' suffix and the 'colon' syntax such as 1551:1559M.
  • There are other version string possibilities. Basically, anything but a sequence of digits will not allow you to release the software. Such a revision number is considered 'clean'.

Assuming that all these constraints have been satisfied, you should be able to release the software. The target migensystem-zip creates a directory in My Documents/Software with the name of the release suffixed by the release number. Inside this you will find a zip file. This zip file consists of all the files in that directory (except the zip itself of course). If you want/need to upload the release, this zip file is what you should use.

Note that in previous versions of the build.xml, it was possible to specify the version number manually if you didn't have subversion installed. This is no longer supported so as to ensure 100% accurate release information.

Releasing from a branch

Releasing from a branch is largely very similar to releasing from the trunk. However, you must note the following:

  • If you are creating a branch from a revision prior to r1559, you will have to copy over trunk's build.xml file so that you have access to the latest targets. DO NOT release using the original build.xml file! You will also need to copy over the Java file uk.ac.lkl.common.util.ReleaseVersionString which the new build.xml uses.
  • The release filename will be generated in exactly the same way as above except that the release number will be suffixed by the branch number in brackets. At present, the repository only consists of a branch called 'universes'. If you were to release from this, you would get a release number that looks something like 1559(universes). This indicates that the release was generated using repository snapshot 1559 but on the universes branch.

Including additional configs with a release for a study or test

After you create a release, go to the directory that has been created with the release and:

  • Add your preferred configuration files in the configs folder.
  • If you want the users to start with one of your files as default, create or edit the configs.txt and change its contents to

StandaloneConfigurationFileSource:<name of your file.txt>
  • Zip the directory

Powered by Google Project Hosting