<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release?<o:p></o:p></p>
<p class="MsoNormal">Could it be acceptable if we break down a big story into several small items which come out in following multiple months, or even quarters?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards<o:p></o:p></p>
<p class="MsoNormal">Yong<o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"Jones, Bruce E" <bruce.e.jones@intel.com><br>
<b>Date: </b>Thursday, 28 June 2018 at 7:48 AM<br>
<b>To: </b>"starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io><br>
<b>Subject: </b>[Starlingx-discuss] RFC: StarlingX release cadence proposal<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a name="_MailOriginalBody">At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we’d like to follow the “bus stop” model of time based releases,
and the Ubuntu model of an annual major (LTS) release with quarterly updates. <o:p>
</o:p></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Note that we did not suggest or agree that our currently planned “Release 2” should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">After separate discussions with David, Dean and Ada, rather than just proposing that “our current November release is the first quarterly release”, I have a modified proposal to make for how
we should handle releases. This is an RFC looking for feedback, questions and comments.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Monthly milestone builds<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">--------------------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Each month in the 2<sup>nd</sup> week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name
for a July 2018 milestone build would be “stx.2018.07”. The version number of that build would be “stx.2018.07.0x”, where “0x” is a patch number. Yes, that’s a change to how version numbers are handled. See below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a “latest known to be good” build for users and partners, and 3) feed into the quarterly
release.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Quarterly release<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">--------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Each quarter’s quarterly release will be the monthly milestone build from the 2<sup>nd</sup> month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release.
For each quarterly release, the code freeze for that release is the 2<sup>nd</sup> week in the 2<sup>nd</sup> month in the quarter.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Branch handling<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">--------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Branches from the 1<sup>st</sup> and 3<sup>rd</sup> month in a quarter can be short-lived. Branches for the 2<sup>nd</sup> month’s (quarterly) build will live longer and I would suggest at any
given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Why?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">-----<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Why do we release a build from the 2<sup>nd</sup> week of the 2<sup>nd</sup> month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer
or winter holidays.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Impact<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">-------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">The planning for release content for what we are currently calling “Release 2” will need to change. If this proposal is accepted, we won’t have a “release 2” anymore, just a “release stx.2018.08.x”
released in September and “release stx 2018.11.x” released in December. This changes the content we’d have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for
the December build, which would be in testing at that time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Version numbers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">----------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">This proposal also includes a version number change from what the underlying TC product uses today. I think it’s inevitable that the StarlingX project has separate / different version numbers
from TC, but I don’t know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
</div>
</body>
</html>