This document describes the policy for updating juju client packages in a stable supported distro, including LTS.

Juju is an open source tool from Canonical for service orchestration. A typical juju install consists of a “cloud environment” which consists of a set of central state servers and any number of managed services and machines. Each managed machine in the environment runs “agents” which talk to the central state server(s) for that environment. It is critical that the state server and agents be kept in sync, and both of these sets of machines are created, booted, and managed by Juju. The code for the state servers and host machine agents is pulled down by Juju at install time, and could be running on a completely different architecture, different OS release, and even a completely different OS than the juju client.

As such the juju client needs to be periodically updated in order to take advantage of changes in external clouds, agents or new or changing features, etc. Therefore, in addition to bug fixes, new features are allowed in an update as long as the conditions outlined below are met.

QA Process

Juju practices continuous integration and testing of the juju source tree. All voting tests must pass for ubuntu before an SRU can be considered. After a build is blessed, it can be considered for release as an SRU provided:

• The licenses and copyrights are correct for all dependencies in the release candidate.
• In the case of an alpha, beta, or minor release, we have documentation for the release notes.
• There are no unfixed bugs tagged "blocker" on the milestone which means a promise to stakeholder that an issue will be fixed in the milestone.

Full details on the QA process can be found here.

Packaging QA

When creating the package for upload, care must be taken to ensure a clean diff.

• All autopkgtests must pass -- test them locally!
• The package must not break when upgrading
• The binary should be identical to the CI build, with only debian packaging changes
• The copyrights and changelog have been updated accordingly
• Double check resulting binary can both bootstrap and deploy!
• Check tab completion (has regressed in the past for reasons unknown)

Requesting the SRU

The SRU should be requested as usual (StableReleaseUpdates) with the additional note about having the above steps being completed. The following template should be applied:

[SRU Information]

juju-core has a stable release exception, including for major version updates, https://wiki.ubuntu.com/JujuUpdates.

[Impact]

State the impact of the change, including brief summary of changes from archive version.

Provide a link to bugs targeted

[QA/Testing]

Provide a link to the successful CI testrun

Provide affirmation of manual testing of proposed package