Cosmo Release Process

Specific releases

• Cosmo 0.7 release planning and tracking

Workflow

Roles

RM: Release Manager (Ted)
QA: QA Contact (Adam)
BRE: Build/Release Engineer (Bear)

Release Candidate Checklist

1. (RM) Make sure all bugs assigned to the release's target milestone in Bugzilla are RESOLVED, VERIFIED or CLOSED.
2. (BRE) Tag and build the release candidate
   • Update the version number in all appropriate pom.xml files, changing to 0.16.0-rc1 (modifying for actual version and rc numbers as appropriate) (tools/set_pom_version.py -v 0.16.0-rc1 is the best way to do this)
   • Deploy the Release Javascript JAR with cd cosmo-js; mvn -Prelease deploy
   • Tag the source code in Subversion (the source URL will refer to the release branch for major and minor releases, to a maintenance branch for maintenance releases):
     • svn copy svn+ssh://svn.osafoundation.org/svn/server/cosmo/branches/0.16 svn+ssh://svn.osafoundation.org/svn/server/cosmo/tags/rel_x.y.z-rc1
   • Update the version number in all appropriate pom.xml files, changing to 0.16.0-SNAPSHOT
   • Deploy the Development Javascript JAR with cd cosmo-js; mvn deploy
   • Have Tinderbox generate the release candidate build and copy it to the downloads server. The easiest way to do this is to run $COSMO_HOME/tools/push_binaries.sh 0.16.0-rc1. You'll need to have appropriate permissions on the relevant servers, as well as the build machine ssh passphrase. Please contact travis@osafoundation.org or cosmo-dev@osafoundation.org if you need this information.
   • Email cosmo-dev that a release candidate is available for download.
3. (QA) Perform acceptance tests
   • Install the release candidate build on qa-cosmo
   • Email cosmo-dev that the release candidate installed cleanly and that testing has started
   • Perform basic Chandler/Cosmo integration tests
   • If accepted, email cosmo-dev to announce acceptance of the release candidate build.

Final Release Checklist

1. (RM) Make sure all bugs assigned to the release's target milestone in Bugzilla are RESOLVED, VERIFIED or CLOSED.
2. (RM) Update the release notes (found in svn at docs/trunk/sites/cosmo/release_notes.php).
3. (BRE) Tag and build the release
   • Update the version number in all appropriate pom.xml files, changing to 0.16.0 (modifying for actual version numbers as appropriate) (tools/set_pom_version.py -v 0.16.0 is the best way to do this)
   • Deploy the Release Javascript JAR with cd cosmo-js; mvn -Prelease deploy
   • Tag the source code in Subversion (the source URL will refer to the release branch for major and minor releases, to a maintenance branch for maintenance releases):
     • svn copy svn+ssh://svn.osafoundation.org/svn/server/cosmo/branches/0.16.0 svn+ssh://svn.osafoundation.org/svn/server/cosmo/tags/rel_x.y.z
   • Update the version number in all appropriate pom.xml files, changing to 0.16.1-SNAPSHOT
   • Deploy the Development Javascript JAR with cd cosmo-js; mvn deploy
   • Have Tinderbox generate the release candidate build and copy it to the downloads server. The easiest way to do this is to run $COSMO_HOME/tools/push_binaries.sh 0.16.0. You'll need to have appropriate permissions on the relevant servers, as well as the build machine ssh passphrase. Please contact travis@osafoundation.org or cosmo-dev@osafoundation.org if you need this information You can also find more information on this process at CosmoReleaseDownloads.
   • Email cosmo-dev to announce the release build's availability for download.
4. (BRE) Update the version numbers listed on:
   • DownloadChandlerServer
   • CosmoHome
   • http://downloads.osafoundation.org index pages: / and cosmo/ and cosmo/releases/
5. (RM) Update the online documentation, including:
   • (hold till Preview) ChandlerServerEndUserManual, for client configuration instructions, end user visible web console features, and FAQs
   • (hold till Preview) CosmoAdministrator, for installation and configuration instructions, operational features, and FAQs
   • (RM) CosmoDevelopmentHome, for protocol notes, client and server API docs, and FAQs
   • (RM) CosmoHome, for current release version number, date, summary, and download and bugs fixed links
6. (RM) Log a bug and send and email to Jared to have osaf.us upgraded.
7. (RM) Announce the release, including the same information from the project home page:
   • on the OSAF blog (be sure to check the Cosmo category)
   • (RM) on the mailing lists. Cosmo mailing list, Chandler mailing list, General mailing list.
   • (RM) on Freshmeat

Target Milestone Query

Release Numbering

Cosmo uses a three digit numbering scheme: <major-version>-<minor-version>-<maintenance-version>

The major version number is bumped only for product releases with significant architectural and/or feature changes. Major releases occur extremely infrequently, probably only every few years. Example: 1.0.0

The minor version number is bumped for releases that incorporate a number of smaller feature additions/changes, usually accompanied by small or isolated design changes and refactoring. Minor releases usually occur every 3-6 months. Example: 1.1.0

The maintenance version number is bumped for bug fix releases. Maintenance releases occur whenever significant bugfixes are necessary, sometimes within weeks of each other. Example: 1.1.1

Source Code Control

Most major and minor version development is done on the trunk. Changes that are likely to introduce instability during development can be done on "feature branches" and then merged into the trunk when stabilized.

When a major or minor release is made, a maintenance branch is created so that bug fixes against that release can be made in isolation while development on the next major or minor release occurs on the trunk. When a maintenance version is released, all changes between that release and the previous one (e.g. between 1.1.0 and 1.1.1) are merged to the trunk.

Whenever any type of release is made, a tag is created to preserve a snapshot of the release source code for archival purposes.

Build Steps

The steps to build a full release or a checkpoint are exactly the same - what's different is the version and tag names.

• Checkpoint
  • version number: 0.5-CP-r2573-20060928
  • tag name: cp_0.5.0-r2573-20060928
• Release
  • version number: 0.7.0
  • tag name: rel_0.7.0

Steps to building a release:

1. decide on the version/tag name and from where in the source tree the source comes from
2. copy withing svn the source to the new tag name - the example assumes a trunk copy to a TAGNAME version

   • svn copy svn+ssh://svn.osafoundation.org/svn/server/cosmo/trunk svn+ssh://svn.osafoundation.org/svn/server/cosmo/tags/TAGNAME

   • Use the following as the commit message: "Tagging SOURCE as Release/Checkpoint VERSION"
3. In a clean directory checkout the tag:

   svn co svn+ssh://svn.osafoundation.org/svn/server/cosmo/tags/TAGNAME

4. Edit the following files to set the version number. Remember for a release the version number is X.Y.Z and for a checkpoint X.Y-CP-r####-YYYYMMDD
   • The following files only need the parent version number set:
     • jsonrpc-java-js/pom.xml
     • olson/pom.xml
     • migration/pom.xml
     • snarf/pom.xml
   • The Dojo file is a bit special - you need to change the parent version and I also add a qualifier to it's version - normally 0.4.1-XYZ where XYZ is the version number minus any punctuation
     • dojo/pom.xml
   • The Cosmo file is special on in that you first change the parent version but then also need to change the two references for Dojo to be the Dojo version
     • cosmo/pom.xml
5. svn commit the version information change with the following commit message "Setting version information for Release/Checkpoint VERSION"
6. in dojo/ run mvn -Prelease deploy - this will generate the dojo jar, build it and then send it to the repository
7. in cosmo/ run mvn -Prelease package - this will generate the cosmo war file
8. in migration/ run mvn -Prelease package - this will generate the migration jar file
9. in snarf/ run mvn -Prelease package - this will generate the Cosmo Server bundle
10. Sanity check the bundle by copying snarf/dist/osaf-server-bundle-VERSION.tar.gz to a temp directory, extract it and check the following:
    • cd into bin/ and run ./bin/osafsrvctl start
    • monitor logs/osafsrv.log for any errors and watch it while you browse to http://localhost:8080/
    • stop the service with ./bin/osafcrvctl stop
    • look into tomcat/webapps/cosmo/js/lib/dojo/ and double check that the dojo.js bundle has the cosmo js bits
11. Send the release to the download server:
    • see bear for details on how to actually do this - don't want to publicize back-end server details
12. Annouce to the cosmo-dev list that a new Release/Checkpoint is available