Making releases

Main tarballs (#)

Cutting a new release is automated, you use the ./scripts/ script after double-checking version strings across the code repository:

  • scripts/lib/gt4.0/brokerdist/
  • scripts/lib/gt4.0/dist/
  • cloud-client/builder/
  • control/src/python/workspacecontrol/main/
  • pilot/
  • cumulus/authz/pynimbusauthz/

You can also use a script that does this all on a remote node where a webserver resides. This is what the Nimbus committers uses on the web server to cut every set of release tarballs and any intermediate ones. See the original commit message for usage.

Cloud client (#)

Most cloud client releases do not need to happen in tandem with a service release because the protocol rarely changes.

Making a new cloud client release involves getting the "workspace/vm/cloud-client" tarball builder and reading its README.txt.

The cloud client has its own CHANGES.txt and README.txt files that need updating.

Transfer the final result to the usual place, "[email protected]:/www/"

It's a good thing to help out and note on the download page which version of the cloud client is actually compatible with various clouds. Especially if there are no clouds that a new version is compatible with, this can happen right after a release of the service and cloud client.

Context agent (#)

The context agent is released more "manually", there is no release generation script, it is just a tarball of your efforts.

$ cp -a context-agent nimbus-ctx-agent-2.3.0
$ find nimbus-ctx-agent-2.3.0 -name CVS -type d -print -exec rm -rf {} \;
$ tar cvzf nimbus-ctx-agent-2.3.0.tar.gz nimbus-ctx-agent-2.3.0