|
V2 /
ReleasesV2.Releases HistoryHide minor edits - Show changes to output Changed lines 44-47 from:
to:
* 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 Changed lines 37-38 from:
* mvn release:prepare to:
* 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 ... Changed lines 36-37 from:
* mvn: to:
* mvn release:clean * mvn release:prepare Deleted line 38:
Changed line 20 from:
!!!Generating a to:
!!!Generating a release via Hudson Added lines 31-38:
!!!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 ... Changed lines 23-26 from:
* * 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 to:
* Go to http://hudson.stonekeep.com - Hudson will do all the branching, tagging, and pom file editing : Added line 30:
* The new build will be on nimitz in /var/lib/maven/stoneport.com/releases/com/stonekeep/congo/congo/ Changed lines 23-33 from:
* 'tag' this release as 2.0.1.2 in to:
* '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) Changed lines 18-19 from:
to:
* 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. Changed lines 21-23 from:
to:
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'. Changed lines 14-17 from:
@@<groupId>com.stonekeep.congo</groupId> to:
@@<groupId>com.stonekeep.congo</groupId>@@\\ @@<artifactId>congo</artifactId>@@\\ @@<version>2.0.1.2-SNAPSHOT</version>@@\\ @@<packaging>war</packaging>@@\\ Changed lines 14-17 from:
to:
@@<groupId>com.stonekeep.congo</groupId> @@<artifactId>congo</artifactId> @@<version>2.0.1.2-SNAPSHOT</version> @@<packaging>war</packaging> Added lines 10-17:
!!!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> Added line 9:
* '-SNAPSHOT' - appended by the build system for 'on the fly' builds. Added lines 1-9:
!!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. |