Releases

• The new build will be in the 'target' subdirectory:

 yacht:CONGO v2 trunk dbs$ ls -l target/congo*.war
 -rw-r--r--  1 dbs  staff  24386297 Oct 17 08:49 target/congo-2.1.0.4.war

• mvn release:prepare
  Answer questions that come up - in general, the defaults are fine:

 [INFO] Checking dependencies and plugins for snapshots ... 
 What is the release version for "CONGO"? (com.stonekeep.congo:congo) 2.1.0.4: : 
 What is SCM release tag or label for "CONGO"? (com.stonekeep.congo:congo) congo-2.1.0.4: : 
 What is the new development version for "CONGO"? (com.stonekeep.congo:congo) 2.1.0.5-SNAPSHOT: : 
 [INFO] Transforming 'CONGO'...
 Build should be in ...

• mvn release:clean
• mvn release:prepare

Generating a release via Hudson

Generating a release via Maven on the command line

Occasionally Hudson is not available or is acting wonky. Here's the steps to do a build / release on the command line. Details here make the same assumptions as above.

• Commit all changes against the trunk
• cd to your working directory (where the pom.xml file is)
• mvn:prepare
• mvn:release
• Build should be in ...

• Go to http://hudson.stonekeep.com - Hudson will do all the branching, tagging, and pom file editing :

• The new build will be on nimitz in /var/lib/maven/stoneport.com/releases/com/stonekeep/congo/congo/

• 'tag' this release as 2.0.1.2 in svn
• Modify pom.xml to have 2.0.1.3 in it
• Check in pom.xml against the trunk (meaning that the 2.0.1.3 change will not be in the 2.0.1.2 branch)
• Go to http://hudson.stonekeep.com :
  • Click on the project 'congo-v2'
  • Click on 'perform maven release'
  • Click on 'specify release version'
    • Release version should be 2.0.1.2
    • Development version should be 2.0.1.3-SNAPSHOT
  • Select Schedule Maven Release Build

(further docs needed)

• The 'current' version in the above notation should be 'above' the current release. Ala, for the above example, the most recent tag/release should be 2.0.1.1. The current version being worked on is '2.0.1.2' - that will be the 'next' release.

A release should be done when patches are complete, and a build is ready to be punched out to run on a customer-facing site. The following process assumes the same versions as above - IE, 2.0.1.1 is the latest release, 2.0.1.2 is being worked on.

• Commit all changes against the trunk.
• 'tag' this release as 2.0.1.2 in 'svn'.

Generating a release

<groupId>com.stonekeep.congo</groupId>
<artifactId>congo</artifactId>
<version>2.0.1.2-SNAPSHOT</version>
<packaging>war</packaging>\\

@@<groupId>com.stonekeep.congo</groupId> @@<artifactId>congo</artifactId> @@<version>2.0.1.2-SNAPSHOT</version> @@<packaging>war</packaging>

Philosophy

• All development is done against the v2 trunk. (in SVN: /svn.stonekeep.com/svn/congo/v2/trunk )
• "current" build numbers are in the pom.xml:
  <groupId>com.stonekeep.congo</groupId> <artifactId>congo</artifactId> <version>2.0.1.2-SNAPSHOT</version> <packaging>war</packaging>

• '-SNAPSHOT' - appended by the build system for 'on the fly' builds.

How to do releases

Release Numbers

CONGO uses version numbering of a.b.c.d[-SNAPSHOT].

• 'd' values are build-releases. Patches for bug fixes and feature inclusion should increement this value.
• 'c' When patches are completed, and a new feature set is included, we jump 'c' and reset 'd' to 0.
• 'b' Should be updated only when MAJOR functionality is altered, such as entire new modules, etc.
• 'a' Should never be changed.