Tagging a New QWG Release

Table of Contents

1. Updating templates/branches
2. Creating a new tag

Instructions below are guidelines for better consistency between contributors to QWG templates and for easier history browsing of modifications.

Modification of QWG templates should be done directly in the trunk. This is the main source of information. In addition to the trunk, they are 2 branches that are in fact copy of the trunk :

• branches/version : this is a middleware version oriented view of the trunk contents (e.g. LCG-2.7.0) and doesn't contain all the SCB base (external/ tools, ant related files...).
• tags : there is one entry per tagged release. This entry is done by svn cp of the relevant branch in templates/branches).

Tagging a new release is a 2 steps process

• Merging relevant changes from trunk to a specific branch.
• Tagging the branch revision as a production release

Updating templates/branches

No change must be done directly in a branch (branches/version), they should go to the trunk first (see Updating the repository?). Branch changes must be merge of changes from trunk and the commit message must state clearly the trunk revision interval corresponding to the commit. Generally, a branch commit includes several unrelated changes from trunk : this is not a problem as long as the commit message states it.

The easiest way to incorporate relevant changes from the trunk into a branch is to use svn merge with a revision interval starting at the last revision merged into the branch (you can get it from the last commit message).

Because a branch is a selected view of the trunk (not everything is in), it is better not to use svn merge on the whole branch but on each branch directory separatly. It is normal to receive warnings about missing targets during the merge : this happens for every part of the trunk that have been removed from the branch. Don't worry too much anyway : before committing the merge, you can revert anything with svn revert (after the commit, you need to do a reverse merge to cancel your change, look at ​Subversion Book for details).

In your commit message, try to use the TracWiki syntax, in particular for bullets, as the rendering is better when browsing the repository with Trac. A typical commit message is :

Merging changes from trunk:686-723, mainly
 * Upgrade of gLite to 3.0.2 (r686)
 * Security update for gLite 3.0.2 (proxy creation, Sept. 06) (r716)
 * VO : update VO ESR configuration (VOMS configuration), add VO proactive (r686, r713)
 * Fix Torque submit filter (account information) (r715)
 * Add fetch-crl to several machine types (r714)
 * Miscellanous reorganization (add standard/pan, move repository_common.tpl fro
m glite-3.0.0 to clusters/example) (r712)
 * Add sharutils (needed on WNs) (r694)
 * Rework of MPI-CH configuration, including re-enabling LAM installation (r693)
 * Miscellanous updates to standard/ (including ncm-accounts upgrade to 2.0.31) (r718)

In this message, you can see that each change is followed by a revision number (or a list of revision numbers) between (). With such a syntax (r + a number), when displayed with Trac, it gives a link to the revision.

It is generally easier to enter such a message in a file and use -F instead of -m in the commit command.

Creating a new tag

Tags are stored under branch templates/tags in the repository. Each tag in this branch must be a copy from the relevant branch, done with svn cp command, for easier identification of the branch version that has been tagged. There should be no commit in a tag revision (you should not do svn co of a tag followed by svn ci, even if nothing prevent it).

A tag name is formed by a prefix designing the middleware variant (e.g. LCG, gLite) and a version number based on the middleware release the templates provide. For example :

gLite-3.0.0-4 : 4th release of templates for gLite 3.0.0
gLite-3.0.2-1 : first release of templates for gLite 3.0.2

As with branch commit, the message must be explicit about the main changes introduced and use the format proposed for branch commit.

Before tagging a new release, be sure to check that examples provided compile successfully. To check this, follow the following steps

• Create a vanilla SCDB
• Load templates to be checked into the vanilla SCDB (with Subversion client or using the tarball)
• Compile with ant, the standard tool for compiling with SCDB

To do these checks, you don't need to run a Subversion server. You just need a Subversion client and Java for running ant.

Below is a check example for gLite 3.0.0 branch (replace with the appropriate one) :

mkdir /tmp/template-validation
cd /tmp/template-validation
svn export https://svn.lal.in2p3.fr/SCDB/trunk .
cd cfg
# In the next command, change the branch to the appropriate one
svn export https://svn.lal.in2p3.fr/templates/branches/gLite-3.0.0 .
cd ..
external/ant/bin/ant

Tool compile-check.sh is executing this set of commands and can be used instead of entering command manually.