StarlingX/Release Plan

Releases

StarlingX is released periodically; one beta release in 2018 and two releases/year starting in 2019. A release consists of a branch in the source code repositories that enables repeatable builds over time.

Release Definition
A StarlingX milestone/release is a tagged branch in the source code repositories that:
 * is considered stable and can be used for repeatable builds
 * will have no additional features added
 * will backport bug fixes for critical/high issues only
 * will be maintained in the canonical repositories for a specified minimum period
 * The list of repos included is maintained in stx-manifest/default.xml (or similar) for any given release. (Note: this file included non-StarlingX-managed repos, only repos from the "starlingx" and "stx-staging" remotes are included.)
 * The actual release is a tag on the corresponding branch, i.e. r/stx.2.0 release branch will be initially tagged as v2.0.0.rc0, the actual release will be tagged as v2.0.0
 * In addition to source, the corresponding binaries will be made available on the StarlingX CENGN mirror (see the the build team page for more details).

Release Cadence and Schedule
Releases are published in a time based fashion:
 * Two StarlingX releases are planned per year / per 12-month period

Formal Releases

 * Released two times per year
 * Branch name format r/stx.X.0
 * 'r/stx' is the branch name prefix (release)
 * 'X' is the major release identifier
 * Release Candidate builds are tagged as X.0 and stored on CENGN at: http://mirror.starlingx.cengn.ca/mirror/starlingx/rc/
 * Formal releases are tagged as X.0.y and stored on CENGN at: http://mirror.starlingx.cengn.ca/mirror/starlingx/release/

Branch Logistics (Historic Only)

 * StarlingX master builds docker images from OpenStack master during the development cycle
 * Once the OpenStack release branch is created (ex: Stein), switch the builds to the release branch
 * Once the StarlingX release branch is created, the master StarlingX builds will switch back to OpenStack master in the default.xml manifest
 * The StarlingX release branch will continue building from the stable OpenStack release branch (ex: Stein)
 * StarlingX maintenance (dot) releases will periodically pick up the latest from the stable OpenStack release branch (ex: Stein)

Release Milestones
StarlingX follows the OpenStack release milestones. The criteria for each milestone is defined to align more closely with the StarlingX deliverables/development cycle
 * Milestone-1:
 * Release priorities and major features defined.
 * High level resourcing secured.
 * Blog Post planning starting
 * Feature PLs / TSC to make recommendations on which features warrant a blog post
 * Milestone-2:
 * Spec freeze; no new specs accepted for the release. The focus is on closing current specs
 * Update: PTG 2021: Agreed that we will no longer have a spec freeze milestone.
 * Feature plans defined and feature development well underway
 * Release test plan defined - including test automation deliverables
 * Milestone-3:
 * Feature freeze: All feature code merged and feature testing completing within an acceptable timeframe
 * No blocking issues from Automated Sanity and Regression
 * No critical issues severely impacting system stability or release test activities
 * Release regression testing starting
 * Documentation plan defined; including a prioritized list of the various documentation items
 * Blog Posts available
 * RC1 (aka RC period start):
 * Release branch created & first release candidate tagged
 * RC binaries (and supporting build artifacts) posted on the StarlingX CENGN mirror
 * RC builds will be posted daily on CENGN during the RC period.
 * The daily builds will not be explicitly tagged until the end of the RC period.
 * Final Release Testing Start
 * Only Bug fixes are allowed in the release branch.
 * Bugs fixes must be sourced in master first before getting cherry-picked to the release branch.
 * Draft Release Notes available
 * Blog Posts available (if not done at Milestone-3)
 * Final Release
 * Release Testing Complete and Pass Rate meets project criteria (> 95% ?)
 * All release gating issues are addressed or reviewed/accepted for deferral
 * Release tagged on release branch
 * Release binaries (and supporting build artifacts) posted on the StarlingX CENGN mirror
 * Final documentation posted on docs.startlingx.io

Release Maintenance

 * Formal releases are maintained for a minimum of 12 months to maintain support for two previous StarlingX releases.
 * During the maintenance window, the release team will evaluate whether a maintenance release is required (upon request)
 * The maintenance release will be tagged on the release branch.
 * The maintenance release will undergo a mini regression test cycle.
 * The corresponding binaries will be posted on the StarlingX CENGN mirror.
 * After the 12-month maintenance window, the release will be considered End of Life.

List of Releases
Planned

Release Planning References

 * For team members and other information, visit the StarlingX Releases sub-project wiki page here
 * Release Planning Etherpad: https://etherpad.openstack.org/p/stx-releases
 * stx.2.0 Release Plan: here
 * stx.3.0 Release Plan: here
 * stx.4.0 Release Plan: here
 * stx.5.0 Release Plan: here
 * stx.6.0 Release Plan: here
 * stx.7.0 Release Plan: here
 * stx.8.0 Release Plan: here
 * stx.9.0 Release Plan: here