GOAL Test & Release Policy

This page describes how we release versions. This applies both for GOAL releases and for environment releases.

Test Policy

ALPHA release

A release labeled as alpha release has undergone no special tests. The only tests that were done were to check bug fixes, and a basic test run of all environments and examples included with the release. Test releases may check even less

BETA release

This policy describes the minimal testing that is performed before a GOAL release is labeled a beta release (see also below). Platform compatibility tests

GOAL is installed on the following platforms and it is verified that the GOAL IDE can be launched without any problems:

  • Windows 32 bits (XP, Vista).
  • Mac OSX (10.4 both Intel and PPC, 10.5 for Intel only).
  • Linux 32bits: Debian Etch, Ubuntu Hardy, OpenSuse 10.3.

Environment tests

On each of the platforms listed above, all of the GOAL agents and environments distributed with the release are tested to verify that they can be successfully run on these platforms.

Feature testing

All bug fixes and enhancements since the previous release have been tested. For each ticket on Trac that is tested for a particular release, the 'Tested' field should be updated by adding the SVN version number of the tested version to the field. (The 'tested' field is to be added to tickets)

NB: Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. Also note that this test policy does not conform to what is labelled beta testing where software versions known as beta versions are released to a limited audience outside of the programming team. Instead all our releases are currently made available to the open public.

Release Policy

In order to identify the release version of GOAL each release of GOAL is time-stamped with the release date and includes the SVN version number that refers to the version number of the code in the software repository (svn number). That is, if a new release of GOAL is made available in year yyyy, month mm, and date dd based upon code with svn version number vvv, then the release version is referred to by using the release identifier yyyymmddvvvv.

Correspondingly, the name of the installer for each release includes the release identifier and the installer is named: goalyyyymmddvvvv.jar. For example, goal20090423v508.jar would be the installer released on April 23th 2009 and be based on the code in the GOAL svn repository that has verion number 508.

In addition, the first window shown when the installer is launched includes a reference to the release version as follows:

This is GOAL release dated yyyymmdd version vvv.

As we realize there is a difference between releases that have been extensively tested versus releases that have not been so tested, we distinguish between so-called beta and final releases. Beta releases have not been extensively tested. Final releases in contrast have been tested more extensively although it should be realised that exhaustive testing is infeasible and final releases may contain bugs. As should be clear from the testing policy outlined above, however, final releases have been successfully tested on various platforms including variants of windows, linux, and mac OSX.

In order to differentiate beta from final releases, immediately below the statement including the GOAL release identifier on the next line the type of release will be identified by either:

Release yyyymmddvvvv is a beta release and has not been extensively tested.


Release yyyymmddvvvv is a final release and has been tested.

This policy has been partly based on Jeff Atwood's comments on version numbering.

Release detailed description

[TODO: can we use]

In order to keep track of what is distributed in a release, with each release on the Trac release page a description of the content is described by:

  • a listing of the packages that have been included in the release at the highest level of inclusion (i.e. src/goal if all packages below src/goal have been included in the release, or e.g.src/goal/core, etc. when this is not the case).
  • a listing of the environments that have been included in the release with their corresponding SVN version number (i.e. the corresponding jar files included in the release with its version number).
  • a listing of all the .mas and .goal files that have been included in the release with their corresponding SVN version number.
  • a listing of all the documentation included in the release with corresponding dates indicating when each document was last updated.

If no changes have been made in the distributed content other than at the code level itself, on the release page will be stated that the release content has not been changed as follows:

Content: description is identical to release yyyymmddvvvv

where the release identifiers refer to the corresponding releases. In addition, minimal changes such as changes in SVN version number of agents can be indicated by statements such as:

Changes compared to yyyymmddvvvv: elevatoragent.goal v481.

An example release description:

Release 2009/04/23 v 508.




blocksworld.jar v505

elevator.jar v493

GOAL agents:

blocksworld.mas v494, stackbuilder.goal b431

elevator.mas v487, elevatoragent.goal b432


GOALProgrammingGuide.pdf dd20090316

Type: alpha.

An example follow up release description:

Release 2009/04/25 v 510.

Changes compared to 20090423v508:

elevatoragent.goal v475.

Type: alpha.

Last modified 8 years ago Last modified on Feb 26, 2011, 10:49:53 PM