Skip to content

Releases

Releases

The main publicly announced releases related to ACCESS OM3 are releases of model configurations. Model configurations include a version of the model software, and are known to be reasonably stable. All of ACCESS-NRI's model configuration releases can be viewed here.

Releases are announced on the ACCESS-HIVE forum and citable through DOI's published on zenodo.

The stages (alpha, beta, full) and standard for releases are defined in the ACCESS-HIVE docs.

Releases are prepared in branches with the dev- prefix, and the merging of a pull request from a dev- branch in the corresponding release- branch triggers an action to create the github release. As such, the pull request acts as the final approval for a release. See contributing in model-config-template for details on this process and explanation on versioning applied.

There is a checklist for developers to follow when undertaking releases. When undertaking releases, the following actions are needed to implement the items on the checklist for developers:

  • Move inputs from /g/data/vk83/prerelease/configurations into /g/data/vk83/configurations using model-config-inputs. 1

  • Update/confirm the version of model-config-tests

  • Reserve a DOI2. Go the existing DOI click new version and save the draft. Add the new DOI to CITATION.cff.

  • Check other details in CITATION.cff, (e.g. versions, descriptions, contributors)

  • Release notes should be drafted and reviewed before completing release. Use this release note for both github and access-hive forum .

  • After the release, navigate to the page for the new DOI and upload the tarball from the github release and fill in any details before publishing the DOI.

  • Create a tag on the main branch to represent the current state of the config documentation. Tags should used the prefix docs- and follow CALVER. For example, if a config is released in August 2025, create a tag from the main branch with the name docs-2025.08.000 3.

Control Experiments

If sharing data from a control experiment, typically run the control experiment as the last action before merging dev- into release-. i.e:

  • Prepare, finalise and review the configuration and have the PR from dev- into release- finalised but not merged
  • Run control experiment from head of dev-
  • If control experiment runs sucessfully, then merge release and announce on access-hive
  • Add Experiment to the Experiments page

  1. Use the same version (CalVer) between prerelease and release folders. for example: /g/data/vk83/prerelease/configurations/inputs/access-om3/cice/grids/global.25km/2025.11.27/kmt.nc moved to /g/data/vk83/configurations/inputs/access-om3/cice/grids/global.25km/2025.11.27/kmt.nc ↩

  2. There is one Concept DOI for all access-om3 configuration releases. Individual releases are new versions under this DOI. Release managers will need to have the 'Curator' Role on the ACCESS-NRI Zenodo Community. ↩

  3. To correct documentation related to a prior release, use patch versions, e.g. docs-2025.08.000.1 ↩