CoG jglobus/Release Process

Release Process

• Propose release on CoG Developer mailing list
• Update in jglobus module:
  • jglobus/build.properties with version numbers
  • jglobus/src/org/globus/common/Version.java with version number
• Update in jglobus-fx module:
  • jglobus-fx/build.properties with version number
• Tag release candidate
• Test release candidate
  • Until automated tests are setup, the following committers are responsible for testing:
    • GridFTP: John
    • GRAM2: Miheal
    • Security: Rachana
    • Others?
• Generate Java Docs
• Update jglobus/CHANGES.TXT and jglobus-fx/gsi/CHANGES.TXT with release number
• Tag for release.
• Update download page:
  • http://wiki.cogkit.org/index.php/Table

GT 4.2.x Release Coordination

• Prior to GT release, determine if there are changes for a CoG release
• If needed, release new version
• Include latest version to GT modules (wsrf)

GT 4.0.x Releases Coordination

• GT 4.0.x consumes modules from globus_4_0_branch
• No changes that breaks backwards compatibility can be made on this branch.
• Maintain branch and if updates have been made, update GT modules (wsrf) with latest jars from the branch.

Guidelines on version number changes

• If change is only bug fix, update PATCH version
• If change is new feature or significant change, update MINOR
• If change breaks backwards compatibility, update MAJOR. This should be RARELY done and backwards compatibility must be maintained. If a backward incompatible change is added, it also requires that a separate branch be created for s/w that depends on the old APIs.