Closing the "latest" track for all observability charms

announcements and community
, ,
1

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.

7 Likes
2

This change seems to be tackling a very real problem, but I am still a little hesitant to say this is the right way to go about it for the sake of clarity of use.

As a user trying to deploy a charm, my main concern is version of the “primary” workload, as that informs about core functionality of the app I need, and in the end of the day, charms are just a way to get the apps I want on clouds I have and manage them. This feels almost like adding another logical but hard for an outsider to understand versioning format on top of all the versioning we’re already doing.

Have you guys looked into this from the point of view of understanding of what I would be getting from this change as a person wanting to deploy a piece of supported, secure app of a specific version? Does this track rename give me confidence I know what I’ll be getting, or this primarily useful for people maintaining the charm?