This LGTM. I would add one more bullet item to the definition: * can re-built at a later date e e.g. to add a fix. So anything that might impact the build should be branched, including (possibly) stx-tools. If/when we ever start hosting binaries, we’ll want to branch everything from the toolchain on up. brucej From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Wednesday, July 18, 2018 11:51 AM To: Hernandez Gonzalez, Fernando <fernando.hernandez.gonzalez@intel.com> Cc: Troyer, Dean <dean.troyer@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Design and Documentation for our Starlingx/Release Plan Web Page. [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@intel.com<mailto:fernando.hernandez.gonzalez@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@gmail.com<mailto:dtroyer@gmail.com>