Skip to main content
Version: 3.6

How to do an OpenRefine version release

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 RefineServlet.java 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. The download links can point directly to Maven Central and can be built as follows (replace 3.6-rc1 by your version string):
  2. Announce the beta/release candidate for testing
  3. Repeat build/release candidate/testing cycle, if necessary.
  4. Update the OpenRefine Homebrew cask or coordinate an update via the developer list
  5. Verify that the correct versions are shown in the widget at http://openrefine.org/download
  6. Announce on the OpenRefine mailing list.
  7. Update the version in master to the next version number with -SNAPSHOT (such as 4.3-SNAPSHOT)
mvn versions:set -DnewVersion=4.3-SNAPSHOT
  1. If releasing a new major or minor version, create a snapshot of the docs, following Docusaurus' versioning procedure.

Apple code signing

We have code signing certificates for our iOS distributions. To use them, follow these steps:

Currently the signing of our releases is disabled because it is blocked by a dependency (#4568)