Skip to main content

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 and in the POM files using mvn versions:set -DnewVersion=2.6-beta -DgenerateBackupPoms=false. Commit the changes.
  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. For example:
git tag -a -m "Second beta" 2.6-beta.2
git push origin --tags
  1. Create a GitHub release based on that tag, with a summary of the changes as description of the release. Publishing the GitHub release will trigger the generation of the packaged artifacts, which will be added to the release on GitHub.
  2. Once the artifacts are ready, update the releases.json file in the repository to reflect this new version. Verify that the correct versions are shown at
  3. Update the OpenRefine Homebrew cask or coordinate an update via the developer forum
  4. Announce on the announcements section of the OpenRefine forum, or even on the blog if this is a major release (the blog is imported automatically into the announcements category of the forum)
  5. Update the version in master to the next version number with -SNAPSHOT (such as 4.3-SNAPSHOT), in the same places as in step 2.

Apple code signing

We have code signing certificates for our iOS distributions. Those are available in our build environment and you should not need to import them to your own machine to make a release (since you are not building the release yourself). But if the signing process fails, it can be useful to import the certificates on your own machine to debug the process. To do so: