Creating a release and deploying it

Pre-release

Before a release you should run all the system tests on your local machine.

Creating a release

1. Make sure dodal and mx-bluesky have up-to-date releases by following the processes here and here.
2. Examine the setup.cfg and check whether the versions of ophyd, ophyd-async, bluesky and blueapi are pinned to the correct versions, if necessary merge changes to update them.
3. Run the pre-release workflow here. Click the "Run workflow" drop-down and enter the release version e.g. v9.2.0. The release versions should look like v{major}.{minor}.{patch}. See here if you're unsure on what the release version should be. Run the workflow.
4. Go here and select the newly created draft release.
5. You should now manually go through each line on the release notes and read it from the perspective of a beamline scientist. It should be clear from each what the change means to the beamline and should have links to easily find further info.
6. Publish the release

Deciding release numbers

Releases should obviously be versioned higher than the previous latest release. Otherwise you should follow this guide:

• Major - Changes that will break compatibility between GDA and Hyperion, large code rewrites
• Minor - New features
• Patch - Bug fixes

Deploying a release

Remember to discuss any new deployments with the appropriate beamline scientist. The utility_scripts/deploy/deploy_hyperion.py script will deploy the latest Hyperion version to a specified beamline. Deployments live in /dls_sw/ixx/software/bluesky/hyperion_vXXX.

If you have just created a release as above, you may need to run git fetch --tags to get the newest release.

To do a new deployment you should run the deploy script from your Hyperion dev environment with e.g.

python ./utility_scripts/deploy/deploy_hyperion.py i03

If you want to test the script you can run:

python ./utility_scripts/deploy/deploy_hyperion.py dev

and a released version will be put in /scratch/30day_tmp/hyperion_release_test