Notes on Performing a WebLearn Build/Release
============================================

Versioning
==========

All WebLearn versions have three components.

Major.Minor.Increment (eg: 2.6.1)

Major - This only gets incremented on major version changed and the increment
should be sequential.

Minor - This gets incremented every time a new stable branch of the codebase is
created and even numbers are used for stable builds and odd ones for development.
2.6.1 is a stable build, 2.7.4 is a development build. Stable builds should only
be found on branches.

Increment - This is the value that gets incremented for each build sequentially,
starting at 0. The increment is specific to a minor version, so each time the
minor of major version is increased the increment is reset to zero.

The versioning started out following the Bodington (http://bodington.org/)
version (2.6) but we seem to be moving at a faster pace so it will probably 
become less of a link as time moves on.

Building
========

Steps to follow to perform a versioned build.

- If there's no branch yet, create it. (I prefer using the Eclipse SVN perspective.)
- Checkout the branch.
- Make sure source tree is up to date (SVN update).
- Increment version number in build.xml (dist.release.tag).
- Commit build.xml back to repository.
- Tag SVN repository with version (eg WebLearn_2_7_2 for build 2.7.2).
- Copy release.build.properties to build.properties
- Run ant clean to make sure there are no SVN problems.
- Generate a new applet signing cert using procedure like:
   keytool -v -list -storepass changeit
   keytool -v -delete -alias tomcat -storepass changeit
   keytool -genkey -keyalg rsa -validity 365 -alias tomcat -storepass changeit
- Run the ant dist target which should produce a zipped build in /dist.

Uploading
=========

In order to make the new build available to the sysdev team, the following
procedure needs to be undertaken.

Upload URL:
https://svn.oucs.ox.ac.uk/projects/vle/deployment/debian/weblearn-classic/trunk

- Check out the 'Upload URL' (see above) from the svn repository.
- Delete the old zip file from this directory.
- Add the new zip file to this directory.
- Commit the deletion of the old file and the addition of the new file as a 
single commit, with a suitable message regarding the value of the new version.
- Inform the sysdev team (most likely via a ticket in the RT system). 

Branching
=========

A new branch should be created for each stable build release. Current convention 
for branch names is to have something like WebLearn_2_6. It is not 
necessary to tag the point on the trunk from which the branch was formed, as 
this can be seen as the earliest revision on the branch with stop-on-copy 
selected. (The corresponding revision on the trunk will be 1 less than this 
revision number).

Releases
========

Any build that runs on the live server should only come from the stable branch.
Every new build should have its version number even if the changes are very 
small to make it easy to track that we have the correct version in testing or 
deployed.

Changelog
=========

You may want a nice changelog of everything that is different between two 
release, this allows you to check that patches made it into the branch. You 
don't need a checkout to get this and the command is something similar to:

svn2cl -r "3721:HEAD"
https://svn.oucs.ox.ac.uk/projects/vle/weblearn/branches/WebLearn_2_16

Here we are asking for a changelog between revision 3721 and the latest point on
the WebLearn 2.16 branch. By default the output is placed in a file called
ChangeLog. svn2cl is in the Ubuntu package subversion-tools or can be grabbed
from http://ch.tudelft.nl/~arthur/svn2cl/