<div dir="ltr">[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: <a href="http://lists.starlingx.io/pipermail/starlingx-discuss/2018-July/000232.html">http://lists.starlingx.io/pipermail/starlingx-discuss/2018-July/000232.html</a>]<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 16, 2018 at 5:54 PM, Hernandez Gonzalez, Fernando <span dir="ltr"><<a href="mailto:fernando.hernandez.gonzalez@intel.com" target="_blank">fernando.hernandez.gonzalez@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-8243131037129389235WordSection1">
<p class="MsoNormal">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.</p></div></div></blockquote><div> </div><div>I think we need to include a definition of exactly what a StarlingX Release/milestone is:</div><div><br></div><div>* A StarlingX milestone/release is a branch in the source code repositories that:</div><div>  * is considered stable</div><div>  * will have no additional features added</div><div>  * will backport bug fixes for critical issues only</div><div>  * will be maintained in the canonical repositories for a specified minimum period</div><div>  * 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.) </div><div><br></div><div>Based on that definition the release process for a milestone might look like:</div><div>* check out the current repos</div><div>* create branches at either HEAD or a specific SHA</div><div>* push branches back to master repos</div><div>* 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))</div><div>* update default.xml in the stx-manifest stable branch to pull the milestone branches rather than master</div><div><br></div><div>The process for the periodic releases would include the milestone process and additionally:</div><div>* when the RC period is concluded tag HEAD on the stable branches to denote the actual release</div></div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div><br></div><div>dt</div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>