Please take a look into this first proposal, our first approach is releasing something clean and neat, comments and suggestions are well welcome, more things can be added/removed if necessary.
I think we need to include a definition of exactly what a StarlingX Release/milestone is:
* A StarlingX milestone/release is a branch in the source code repositories that:
* is considered stable
* will have no additional features added
* will backport bug fixes for critical 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.)
Based on that definition the release process for a milestone might look like:
* check out the current repos
* create branches at either HEAD or a specific SHA
* push branches back to master repos
* create new review to update the .gitreview file in each repo (this _should_ be the first merge on the new branch, there may be additional branch-specific updates required here at some point (release notes are common))
* update default.xml in the stx-manifest stable branch to pull the milestone branches rather than master
The process for the periodic releases would include the milestone process and additionally:
* when the RC period is concluded tag HEAD on the stable branches to denote the actual release
We should consider if we want to branch stx-tools or not as its intended to be release-agnostic and should not have any release-specific contents. We may want to branch it anyway.