2.7.0 release - documentation planning


#1

Well done on the work that’s gone in this cycle. I want to avoid a situation where features for 2.7.0 have landed that have no public-facing docs (cf multi-cloud controllers that was never done https://discourse.jujucharms.com/t/new-2-6-feature-multi-cloud-controllers/1401/1).

As a stretch goal, I also want Juju to publish some promotional material and have that pushed out through the Ubuntu blog/social channels.

Here is a plan for the docs side of things for the next 3 weeks. It includes a few tasks for you:

Milestone: 2.7.0-beta1

At this stage, we are feature complete. We want to solicit heavy testing from the community to prevent major bugs sneaking into the release.

Call for Testing should be released to Discourse alongside the beta.

Item: “Release Notes”

About Description of changes
Contents developer/power user audience, lots of detail, links to specific bugs
Channel(s) Juju Discourse

What is needed from you:

  • Ensure that features you have worked on is listed
  • Add what needs testing. Suggest copying your QA steps into this page

Item: " New Features and Changes in Juju 2.7"

Late addition

About Details of changes
Contents developer/power user audience, lots of detail
Channel(s) Juju Discourse

Item: “2.7.0 what to expect”

About blog style content explaining the release
Contents headlines, brief description of each feature, link to release notes, link to getting started with Juju
Excludes installation instructions, links to bugs
Channels Juju Discourse, Ubuntu Server Discourse, Ubuntu Twitter, Ubuntu Facebook

What is needed from you:

  • quick check

Item: “2.7.0 call for testing”

About blog style content asking for end-user testing
Contents link to release notes
Channels Juju Discourse, Ubuntu Server Discourse, Ubuntu Twitter, Ubuntu Facebook

What is needed from you:

  • list of things to check & suggested QA steps
  • quick check of the content

Milestone: 2.7.0-rc1

At this stage, we have hit code freeze and expect to release the product after final testing. Only critical bugs will be considered as a reason to require an rc2.

Release docs should also already be done. Finding an error at this stage means that we rushed things earlier.

Promotional material development begins.

Item: “Release Notes”

What is needed from you:

  • final QA

Item: Release Announcement

Channel: Juju Discourse (as draft)
What is needed from you:

  • final QA

Item: “Simplify your ops with Juju”

About Juju pitch for developers
Contents juju selling points, micro tutorial, links
Channel Juju Discourse (as draft)

Milestone: 2.7.0

Item: “Release Notes”

Needed from you:

  • Nothing. You already checked it, right?

Item: Release Announcement

About Inform the world that Juju’s making progress
Contents Summary of key features, pointer to release notes
Channel(s) Juju Discourse, Ubuntu Server Discourse, Ubuntu Twitter, Ubuntu Facebook, Ubuntu Blog

Item: “Simplify your ops with Juju”

About Promotional piece aimed at developers
Contents tbd
Channel Ubuntu blog

Item: “Agility, stability, simplicity: pick 3 for your technology infrastructure”

About Promotional piece aimed at C-suite
Contents tbd
Channel Ubuntu blog

#2

@thumper, @wallyworld, @rick_h does this all make sense?


#3

One comment - typically once we hit RC, starting with RC1, the expectation is that it is job done and we intend to release without any more code changes. We only allow subsequent commits for agreed critical bugs and carefully vet any PRs. We do not want to have to do a RC2. The call for testing goes out with beta1 to allow any last minute fixes to land to prepare for RC. In an ideal world, we’d just flip the RC binary to release but of course do need to doa recompile to bake in the release version number, but that is the only change between RC and release binaries.


#4

I’ve moved the call for testing to beta1 and removed rc2 as a milestone.


#5

I also updated the RC1 text.