Epic Goal

• We need to provide information about what is in each engineering candidate build we produce.

Why is this important?

• Preview users will want to know what changes are coming in each new release. Regular customers, consuming full release builds, will have errata advisories. Those do not exist for EC builds.

Scenarios

1. A user of a preview version of MicroShift can tell what changes are in the next release so they can anticipate what behaviors might be different and tell if the bugs/features they care about are completed, yet.

Acceptance Criteria

• Describe a process for managing the content generally
• Describe a process for identifying what content should be included in the notes for a specific release
• Describe a process for publishing that content, including where to publish to
• Identify an owner for the process or a rotation of owners

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>