# UHPC 003 - Release policy for Charmed Slurm
# Abstract
This specification details the release policy for Charmed Slurm.
NOTE: This is not a binding support contract.
# Rationale
A consistent release policy is necessary to keep our community aware of upcoming major changes, bug fixes, and security updates, while ensuring that the community has some expected degree of stability.
Charmed Slurm comprises:
- Slurm machine charms
- `slurm-wlm` Debian packages
Since Charmed Slurm is a composition of multiple artifacts, there must be a well-defined release policy that developers and users can reference to know when they can expect things such as when the version of Slurm will upgraded, when new features will be added to the charms, where they can go to get security updates, etc.
# Specification
## Charmed Slurm tracking upstream
A new version of Slurm is released every 6 months and receives bug and security fixes support for an 18-month cycle by SchedMD.
[Source](https://www.schedmd.com/slurm-releases-move-to-a-six-month-cycle/)
Charmed Slurm's versioning will map to upstream release of Slurm that it operates. Example:
- Charmed Slurm 25.11 operates Slurm 25.11
- Charmed Slurm 26.04 operates Slurm 26.04
## Release cadence
Charmed Slurm will follow behind upstream Slurm releases by one release - approximately six months. Example:
- Latest Slurm upstream is 26.04, Charmed Slurm 25.11 will be released with Slurm 25.11.
Feature freeze for the next Charmed Slurm release will be up to 6 months after a new version of Slurm is released by SchedMD. This timeframe is for maintainers to add new features to the Slurm charms, and backport the previous release of Slurm to the current Ubuntu LTS release. Example schedule:
- Slurm 26.04 is released by SchedMD.
- Work to backport Slurm 25.11 to Noble Numbat (Ubuntu 24.04 LTS) begins (24.04 LTS includes Slurm 23.11)
- 4 months in - "soft freeze"
- "Soft freeze" implies that no MAJOR changes (feature deprecations, interface breaking changes, new dependencies) will be introduced after this date.
- 2 months after "soft freeze" we have "hard freeze". After "hard freeze" no new changes can be introduced. Bug and security fixes can still be backported.
- After "hard freeze", the new version of Charmed Slurm will be released.
- During the period between the "soft freeze" and "hard freeze" will be allocated to testing Charmed Slurm and fixing known issues. Changes can still be introduced, but major changes will be pushed off to the next release of Charmed Slurm.
## Support life-cycle
Outside exceptional circumstances, each Charmed Slurm release will receive bug and security fix support for 1 year, following the upstream Slurm support life-cycle.
## Versioning scheme for Charmed Slurm
<!--- Julian/Ashley: do we need to have the minor/patch version there? Those are backwards compatible, so having one branch per minor
version seems a lot to handle, and may be better to have the upstream Slurm version be the branch name. --->
Version format: `<upstream Slurm version>-<minor/patch version #>`. Example Charmed Slurm release numbers.
- Slurm 25.11 is now operated by the Slurm charms: `25.11-0`
- Bugfix is released: `25.11-1`
- Security update is released: `25.11-2`.
- Slurm 26.04 is now operated by the Slurm charms: `26.04-0`
* Major release - new version of Slurm, feature changes, new Ubuntu base version
* This version number will only change with the new version of Slurm.
* Minor release - bug and security fixes
* Note that running `juju refresh` is necessary to pull latest security and bug fix updates
### Release channels
* Each track on Charmhub provides three channels:
* Edge, the development channel
* Candidate, test the new release before publishing (to catch early bugs)
* Stable
* Each Slurm major release has its own track, e.g. "23.11".
* Each track has a corresponding GitHub branch, e.g. "23.11", from which releases are made to each of the three channels: Edge/Candidate/Stable
* The corresponding commit hash is included in the charm version on release to a channel, e.g. "Stable f098fc2"
<!--- * The default track for a charm is the track for the most recent Slurm major release.
* E.g. The most recent Slurm major release is 23.11:
* 23.11/edge == revision 40 == latest/edge
* 23.11/candidate == revision 39 == latest/candidate
* 23.11/stable == revision 38 == latest/stable
* When the track for next major release is created, the "latest" track updates to match it. E.g. "latest/edge" becomes equivalent to "24.05/edge", and so on. --->
* No breaking changes should be made to integrations, configuration options, or actions in a stable track of a charm
* To introduce breaking changes, a new track should be created
* No breaking changes will be made to the charm when the Slurm version stays the same
## Documentation
* User is expected to use the charm version (Charmhub track) that comes with a specific Slurm release
* Cannot guarantee backwards compatibility with previous major Charmed Slurm versions
* If a user requirement necessitates versions that are not from the same release, they should open an issue on Github
(or Support Discussion) and contact the team
## Process for updates
* Docementation for migrating to a new version
* Dedicate a team member to doing upgrade/refresh tests
* Ubuntu version updates will likely be more costly than service version
### Security Patches
* Pushed to edge, release after standard testing process
## Supported Artifacts
<!-- List of supported artifacts with source code links and issue tracker refs
-->
## Examples
### Anbox Cloud
[Anbox Release Page](https://documentation.ubuntu.com/anbox-cloud/en/latest/reference/release-notes/release-notes/)
* From home page, Roadmap has its own left-side TOC below contribute
* After selection: Roadmap appears only within references in left-side TOC
* Preferred style, need to figure out sphinx set up
* Has recent releases and upcoming release roadmap
* Has defined release cycle and defined support policy
### Kubernetes
[Kubernetes Release Page](https://ubuntu.com/kubernetes/docs/release-notes)
* Release notes within refs section
* Has a 'what's new' section
* No Roadmap
### MaaS
[Maas Release Page](https://maas.io/docs/reference-release-notes-maas-3-5)
* Each major release has a tab in Refs
# Release notes sections
General Release Notes sections:
* Long-term support or not
* Length of 'long-term'
* Requirements and compatibility
* What's new
* Backwards incompatible changes
* Deprecated features
# References
* [Release Notes Format](https://docs.google.com/document/d/1L-FxU2Si7Mt6TqnTk_CZYPezAajsBKiGDNP65Pf688s/edit?tab=t.0#heading=h.g4gdk7o1d9xn)
* [Documentation Release Notes landing page Format](https://docs.google.com/document/d/187hrGJd-l9WkUarEqw7FLOu_X6k849xaiDp_T9HHDHI/edit?tab=t.0#heading=h.y7atuj5xt6qt)
* [Canonical product release cycles](https://ubuntu.com/about/release-cycle#ubuntu)
* [Kubeflow publish action for charms](https://github.com/canonical/charmed-kubeflow-workflows/blob/main/.github/workflows/_publish.yaml)
* [Other Kubeflow actions](https://github.com/canonical/charmed-kubeflow-workflows/tree/main/.github/workflows)
# Spec History and Changelog
| Date | Status | Author(s) | Comment |
|:--------|:--------|:--------------------|:------------|
| 2025-07-09 | Braindump | [Ashley Cliff](mailto:ashley.cliff@canonical.com) | Initial braindump |
| 2025-07-15 | Braindump | [Ashley Cliff](mailto:ashley.cliff@canonical.com) | Initial braindump |