= Tagging a New QWG Release = [[TracNav]] [[TOC(inline)]] 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 [source:templates/trunk 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. [source:templates/branches/LCG-2.7.0 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 [source:templates/branches]). Tagging a new release is a 2 steps process * Merging relevant changes from [source:templates/trunk trunk] to a [source:templates/branches 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 [wiki:Development/RepUpdate 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 [http://svnbook.red-bean.com/ 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 [source:templates/tags 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 [source:templates/trunk/tools/compile-check.sh compile-check.sh] is executing this set of commands and can be used instead of entering command manually.