OMERO.server release
This document describes the release process for OMERO server. The release process uses GitHub actions, make sure that the actions are active before pushing any tag.
Register CVE
As soon as a vulnerability is identified, create a security advisory on GitHub. The work to fix the vulnerability will be done using the private copy of ome/openmicroscopy and the private copies of the Java components. The release process needs to be adjusted in that case.
Release process
Source code release
- To make a new release:
Merge all contributions on the
developbranch.Ensure that all the dependencies have been bumped via the update GitHub action which is run hourly. The action will open a Pull Request that updates the omero.properties file. Merge the Pull Request. You can also execute locally the script update_dependencies.sh manually if you wish.
Add an entry to history.rst.
- To make a release from a private copy:
Squash all the commits fixing the vulnerability
Ensure that all the dependencies have been bumped using the script :file:update_dependencies.sh
Add an entry to :file:history.rst
After committing the changes, a signed tag must be created for the released version using git tag -s:
$ git tag -s -m "Tag version x.y.z" vx.y.z
Both the develop branch as well as the tag must be pushed upstream:
$ git push origin develop vx.y.z
This will trigger the GitHub action builds, generate artifacts, create a GitHub release and upload the artifacts to the release on GitHub. An hourly cron job runs on our virtual machine and copy the artifacts published on Github under OMERO Downloads.
Docker container release
Before making a new release, ensure that the GitHub actions are still enabled and merge all contributions on the master branch (rare).
When the artifacts are available under OMERO Downloads, you can release the OMERO Server Docker. Bump the version in Dockerfile to the latest release version.
After committing the changes, a signed tag must be created for the released version using git tag -s:
$ git tag -s -m "Tag version x.y.z" x.y.z
Before pushing, make sure that the artifacts have been copied under OMERO Downloads. Both the master branch as well as the tag must be pushed upstream:
$ git push origin master x.y.z
Documentation release
Before making a new release, merge all contributions on the develop branch.
A GitHub action is run daily to synchronize the documentation with changes made in various repositories
e.g. omero-install, omeroweb-install, openmicroscopy, and bump the version of various components e.g. omero-web. The action will automatically open a Pull Request if some changes happened. The Pull Request must be merged before the release.
If you wish to publish the documentation the same day as the source code release, the easiest option is to
modify the format of the cron job in the update.yml GitHub action e.g. cron: '*/10 * * * *' and merge the Pull Request opened by the action.
After fetching the develop branch, revert the change to the cron job made above. A signed tag must be created for the released version using git tag -s:
$ git tag -s -m "Tag version x.y.z" vx.y.z
Both the develop branch as well as the tag must be pushed upstream:
$ git push origin develop vx.y.z
The documentation is built and published on Read The Docs.
An hourly cron job runs on our virtual machine and adds redirect from for example docs.openmicroscopy.org/omero/5.6.13 to omero.readthedocs.io/en/v5.6.13/.
Website release
When the documentation is deployed, you can make a release of the Open Microscopy Environment website.
- To make a release:
Update the version in _config.yml
Add a new entry under _posts. The name of the post should be
YYYY-MM-DD-omero-MAJOR-MINOR-PATCH.mde.g.2024-08-15-omero-5-6-13.mdPoint to the post announcing the release in omero/downloads/index.html.
A signed tag must be created using git tag -s:
$ git tag -s -m "Message" YYYY.MM.DD
Before pushing, make sure that the documentation has been built and published on Read The Docs. Both the master branch as well as the tag must be pushed upstream:
$ git push origin master YYYY.MM.DD
An hourly cron job runs on our virtual machine and deploys the website.
- Finally
Add an entry in https://docs.google.com/spreadsheets/d/1K7ab1UpuiE3FmAq3et7OpyxFwumrT7z8tGrDDBSDxsk/edit#gid=908994883
Announce the release on image.sc using the
Announcementscategory after checking that the website has been deployed.