Hi everyone!
Charms live at the intersection of multiple versions:
- workload versions;
- the Ubuntu base they’re built on;
- the minimum Juju version they assume;
- the charm library versions (LIBAPI, LIBPATCH);
- the versions of their dependencies (pyproject.toml, requirements.txt, etc.).
The combination of these may force a breaking change upon a charm. For this reason, we needed a release mechanism that would accommodate both stability and rapid prototyping.
Having just one latest track, did not address those needs.
Consecutive integer track names for COS charms
Every 6 months, loosely following Ubuntu releases, the current “N” track will become feature-frozen and a new track “N+1” will be created for all charms. COS charm tracks will all move together in lockstep.
Every time we open a new track, we’ll update the platforms
section in charmcraft.yaml
to include the latest Ubuntu LTS as base.
Example:
1/stable: 81 2025-05-13 (81) 19MB amd64 ubuntu@20.04
1/candidate: 82 2025-05-13 (82) 19MB amd64 ubuntu@20.04
1/beta: 84 2025-05-13 (84) 11MB amd64 ubuntu@20.04
1/edge: 87 2025-05-13 (87) 11MB amd64 ubuntu@20.04
2/stable: –
2/candidate: 89 2025-05-27 (89) 11MB amd64 ubuntu@24.04
2/beta: 89 2025-05-27 (89) 11MB amd64 ubuntu@24.04
2/edge: 89 2025-05-27 (89) 11MB amd64 ubuntu@24.04
Closing the “latest” track
Next week we will be closing all “latest” tracks for the COS charms. Please update your workflows to use track “1”. The contents of the “latest” track was released as-is to this new track.
Git
In our repos, we now have the track/1
branch, where we would contribute bug fixes and security fixes, but not new features. The support window for non-LTS tracks is 9 months. The overlap between tracks is to accommodate transitions.
We will announce LTS tracks in a separate post.
Upgradability
In-track upgrades should always be worry free, but cross-track upgrade may involve manual steps. We will be publishing upgrade guides when new tracks are released.