Skip to content

Release Process

Tim Van Steenburgh edited this page May 1, 2017 · 7 revisions

How to Release the Canonical Distribution of Kubernetes


  1. Determine release date

  2. Prepare doc PRs upstream

    1. These are the docs:


      2. Example:

      3. Allow ~4 days lead time to get PR merged before the release?

    2. Only necessary to update these docs when behavior is changing, or new features are being added

  3. Generate changelog and credits (manual)

    1. This goes into the release email

    2. git log cluster/juju in kubernetes/kubernetes on master branch

      1. Commit msgs may not contain all detail

      2. For now we can get extra detail from GH

      3. We need to start putting relevant detail in commit msgs

      4. Script to pull info from GH?

      5. Format: " @gh_handle"

  4. Generate release notes

    1. Template:

    2. Include announcement about EOL’d versions

    3. Send release notes w/ heads-up to James Donner & Marco Ceppi

  5. Regression Tests

    1. Long term this will be done by CI nightly

    2. Meantime:

      1. Run e2e on azure, aws, gce, lxd, openstack (oil lab - larrymi):

      2. Run bundle tests

  6. Green Grid of Testing Goodness


    2. Overview:

    3. Tests expire after 2 weeks




  1. Tag

    1. Pull upstream into juju-solutions/kubernetes

    2. git co master && git tag 1.6.1-20170501 && git push juju-solutions master --tags

  2. Run kubernetes-release**-charms** CI job, passing the git tag for our release, edge channel

    1. For ‘other’ charms, use master for now
  3. Run kubernetes-release**-bundles** CI job, passing the git tag for our release, edge channel

  4. Run mv_bundle for edge -> stable


  1. Post changelog/announcement on

    1. James Donner & Marco Ceppi - they post to i.u.c

    2. Ping James Donner for social media announcements

  2. Announce on appropriate upstream mailing list


    2. Must be subscribed to mail

  3. Post on /r/kubernetes and HN (Marco?)

You can’t perform that action at this time.