[Starlingx-discuss] Design and Documentation for our Starlingx/Release Plan Web Page.

Dean Troyer dtroyer at gmail.com
Wed Jul 18 18:51:19 UTC 2018


[Formatting in these messages is likely to be mangled for many readers and
completely stripped in the archives.  Attachments are also stripped in the
archives.  Here is how the original message looks:
http://lists.starlingx.io/pipermail/starlingx-discuss/2018-July/000232.html]

On Mon, Jul 16, 2018 at 5:54 PM, Hernandez Gonzalez, Fernando <
fernando.hernandez.gonzalez at intel.com> wrote:

> 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.

Thoughts?

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20180718/98b7e951/attachment.html>


More information about the Starlingx-discuss mailing list