Releasing Version

Tom Morris edited this page Aug 15, 2013 · 9 revisions
Clone this wiki locally

Releasing a new version of Refine


When releasing a new version of Refine, the following steps should be followed:

  1. Make sure the `master` branch is stable and nothing has broken since the previous version. We need developers to stabilize the trunk and some volunteers to try out `master` for a few days.
  2. Change the version number in
  3. Compose the list of changes in the code and on the wiki. If the issues have been updated with the appropriate milestone, the Github issue tracker should be able to provide a good starting point for this.
  4. Tag the release candidate in git and push the tag to Github git tag -a -m "Second beta" 2.6-beta.2 git push origin --tags
  5. Set up build machine. This needs to be Mac OS X, but can be run in a VM. The machine also needs a code signing certificate with the name "OpenRefine Code Signing" installed, but this can be a self-signed certificate. It can be created using the OS X Keychain Access utility.
  6. Build the release candidate kits using the shell script (not just Ant). This must be done on Mac OS X to be able to build all 3 kits, although Linux can be used for Linux & Windows builds: ./refine dist 2.6-beta.2
  7. Upload the kits to Github releases If running OS X in a VM, it's probably quicker and more reliable to transfer the kits to the host machine first and then to Github. Finder -> Go -> Connect -> smb:
  8. Announce the beta/release candidate for testing
  9. Repeat build/release candidate/testing cycle, if necessary.
  10. Tag the release in git. Build the distributions and upload them.
  11. Update the releases.js file. This triggers the prompt to users to update their installations, so it should be the final step.
  12. Verify that the correct versions are shown in the widget at

NOTE: During the transition to Github, the releases.js file on Google Code needs to be updated because that's the one that existing installations are looking at. It also needs a fake revision number which is higher than the 2.5 revision to trigger the update. Post 2.6 only Github needs to be updated.

  1. Announce on the mailing list.