r44 - 31 Jul 2008 - 11:07:35 - TravisVachonYou are here: OSAF >  Projects Web  >  CosmoHome > CosmoDevelopmentHome > CosmoReleaseProcess

Cosmo Release Process

Subversion Tag Scheme

  • 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
  • Release Candidate
    • version number: 0.7.0-rc1
    • tag name: rel_0.7.0-rc1

Pom Version Scheme

  • Trunk
    • 0.7-SNAPSHOT
  • Release Branch
    • 0.7.0-SNAPSHOT
  • Release Candidate Tag
    • 0.7.0-rc1
  • Release Tag
    • 0.7.0

Test Cycle

  • Run Java unit tests with cd $COSMO_HOME/cosmo/; mvn test
  • Run Javascript Unit Tests on each supported platform by visiting http://localhost:8080/chandler/js/cosmo/tests/runAllTests.html
  • Run Windmill Test Suite on each supported platform.

Release Candidate Checklist

  1. Make sure all bugs assigned to the release's target milestone in Bugzilla are RESOLVED, VERIFIED or CLOSED.
  2. 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 or cosmo-dev if you need this information.
    • Email cosmo-dev that a release candidate is available for download.
  3. 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. Make sure all bugs assigned to the release's target milestone in Bugzilla are RESOLVED, VERIFIED or CLOSED.
  2. Update the release notes (found in svn at $COSMO_ROOT/doc/). Make sure to use $COSMO_ROOT/tools/format_bugs.sh to generate bug lists.
  3. 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 or cosmo-dev 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. Update the version numbers listed on:
  5. 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
    • CosmoDevelopmentHome, for protocol notes, client and server API docs, and FAQs
    • CosmoHome, for current release version number, date, summary, and download and bugs fixed links
  6. Log a bug and send and email to Jared to have Chandler Hub upgraded.
  7. Announce the release, including the same information from the project home page:

Target Milestone Query

3738

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 1-3 months. Example: 1.1.0

The maintenance version number is bumped for bug fix releases. Maintenance releases occur whenever significant bugfixes are necessary, often 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. Use tools/set_pom_version.py -v VERSION to set the pom.xml version numbers
  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:
    • this process can be automated with the tools/push_binaries.sh script, but requires appropriate permissions on several servers. Please contact Travis or cosmo-dev if you need this information.
  12. Annouce to the cosmo-dev list that a new Release/Checkpoint is available
toggleopenShow attachmentstogglecloseHide attachments
Topic attachments
I Attachment Action Size Date Who Comment
pngpng graph811a8fad4b84daf4e94d2aab7e8f1a90.png manage 1.9 K 11 Jun 2007 - 23:01 UnknownUser  
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r44 < r43 < r42 < r41 < r40 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.