stable: initial stable-branching documentation

It is expected that this document will change over time. This
represents an initial starting point as we create and release
our stable branches.

Fixes: kata-containers#237

Signed-off-by: Eric Ernst <eric.ernst@intel.com>

Stable-Branch-Strategy.md

@@ -0,0 +1,95 @@
+Branch and release maintenance for Kata Containers project
+
+# Overview
+
+As detailed in the release documentation, the Kata Containers project makes use of
+semantic versioning.  A release version is described by MAJOR.MINOR.PATCH.  Early in
+the project, we will introduce many new features which will require a minor version change
+as well as bug fixes.  To facilitate a stable user environment, Kata will begin to provide
+stable branch based releases as well as a master branch release.
+
+## Branch Management
+Kata Containers will maintain two stable release branches in addition to the master branch.
+Once a new MAJOR or MINOR release is created off of master, a new stable branch will be created for
+the prior MAJOR or MINOR release and the older stable branch will no longer be maintained.
+
+A couple of examples are provided to help clarify this process.
+
+### New bug fix introduced
+Consider the following initial state:
+Master 1.3.rc0
+Stable 1.2.0
+Stable 1.1.2
+
+A bug fix is submitted against the runtime which does not introduce new inter-component dependencies.
+This fix will be applied to both the master and stable branch, and the new state will be:
+```
+Master: 1.3.rc1 
+Stable: 1.2.1
+Stable: 1.1.3
+```
+
+### New release made feature or change which  adds new inter-component dependency
+Consider the following initial state:
+```
+Master: 1.3.rc1
+Stable: 1.2.1
+Stable: 1.1.3
+```
+A new feature is introduced which adds a new inter-component dependency. The new branch state will be:
+```
+Master: 1.3.0
+Stable: 1.3.0
+Stable: 1.2.2
+```
+
+Note, the 1.1.3 branch will still exist, but under current plans it would not be maintained further. 
+
+## Backporting Process 
+
+Development will occur against the master branch and applicable code commits should also be submitted
+against the stable branch. Some guidelines:
+-Only bug and security fixes which do not introduce inter-component dependencies are
+candidates for the stable branch. Once a PR is created against master which meets requirement
+of (1), a comparable one should also be submitted against stable. It is the responsibility of
+the submitter to apply their pull request against stable, and it is the responsibility of the
+reviewers to help identify stable-candidate pull requests.
+
+## Continuous Integration Testing
+
+The test repository will also be forked to create stable branches based off of master. Full CI
+will run on each stable and master PR, using its respective tests repository branch.
+
+### An alternative method for CI testing: suggestiong to revisit:
+
+Ideally the continuous integration infrastructure will run the same test suite on both master
+and the stable branches.  When tests are modified or new feature tests are introduced, explicit
+logic should exist within the testing CI to make sure only applicable tests are executed against
+stable and master. This is not in place today, but should be considered in the longer term.
+
+## Release Management
+
+### Patch releases
+
+Releases will be made on a weekly cadence for both stable branches for patch releases. If there
+are no changes across all the repositories, no release will be created. If a release is being made,
+each repository will be tagged for this release, regardless of whether changes have been introduced.
+
+
+## Minor releases
+
+###  Frequency
+Minor releases should be less frequent, though are currently running on a six week cadence. As the
+Kata Containers code base matures it is expected this will become a much longer duration.
+
+### Compatibility
+Kata will guarantee compatibility between components that are within one minor release of each other. 
+
+This is especially critical for dependencies which cross between host (runtime, shim, proxy) and
+the guest (hypervisor, rootfs and agent).  For example, consider a cluster with a long-running
+deployment, workload-never-dies, all on kata version 1.1.3 components. If the operator updates
+the Kata components to the next new minor release (1.2.0), we need to guarantee that the 1.2.0
+runtime can still communicate with 1.1.3 agent within workload-never-dies.
+
+Handling live-update is out of the scope of this document, but will need to be supported so we can
+update workload-never-dies’s agent from 1.1.3 to 1.2.0.