Adding LTS-Strategy document

README.md

@@ -30,7 +30,7 @@ The following is a list of some of the core features needed for a production dep
 
 ## Releases
 
-Aca-py community provides periodic releases with new features and improvements. Additionally, certain releases are designated as long-term support (LTS) releases. Important fixes will be backported to the most recent LTS release, and to the prior LTS release during periods of LTS release overlap. For more details see the [LTS strategy]()<Link to be updated>.
+Aca-py community provides periodic releases with new features and improvements. Additionally, certain releases are designated as long-term support (LTS) releases. Important fixes will be backported to the most recent LTS release, and to the prior LTS release during periods of LTS release overlap. For more details see the [LTS strategy](./docs/LTS-Strategy.md).
 
 Current LTS releases:
 - [0.12.0](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.12.0)

docs/LTS-Strategy.md

@@ -0,0 +1,75 @@
+# Summary
+[summary]: #summary
+
+This document defines the Long-term support (LTS) release strategy for Hyperledger Aries CloudAgent Python (Aca-py). This document is inspired from the [Hyperledger Fabric Release Strategy](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md). 
+
+Long-term support definition from wikipedia.org:
+
+> **Long-term support (LTS)** is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition.
+
+> **LTS** applies the tenets of reliability engineering to the software development process and software release life cycle. Long-term support extends the period of software maintenance; it also alters the type and frequency of software updates (patches) to reduce the risk, expense, and disruption of software deployment, while promoting the dependability of the software.
+
+# Motivation
+[motivation]: #motivation
+
+Most of the Aca-py users rely upon using the [Docker images](https://github.com/hyperledger/aries-cloudagent-python/pkgs/container/aries-cloudagent-python)  which are published nightly and along with the [releases](https://github.com/hyperledger/aries-cloudagent-python/releases). These images contain the project dependencies/libraries which needs constant security vulnerability monitoring and patches based on the updates available from opensource.
+
+This is one of the factors which motivated setting up the LTS releases which requires the docker images to be scanned regularly and patching them for vulnerabilies. 
+
+In addition to this, administrators can expect the following of a LTS release:
+
+- Stable and well-tested code
+- A list of supported RFCs and features for each LTS version from this [document](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md).
+- Minimal set of feature additions and other changes that can easily be applied, reducing the risk of functional regressions and bugs
+
+Similarly, there are benefits to Aca-py maintainers, code contributors, and the wider community:
+
+- New features and other changes can quickly be applied to the main branch, and distributed to the user community for trial, without impacting production deployments.
+- Community feedback on new features can be solicited and acted upon.
+- Bug fixes only need to be backported to a small number of designated LTS releases.
+- Extra tests (e.g. upgrade tests for non-subsequent versions) only need to be executed against a small number of designated LTS releases.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+## Release cadence
+
+Aca-py will continue the pattern of minor releases, e.g. 0.10.5, 0.11.1, 0.12.0, 0.12.1 etc.
+
+## LTS release cadence
+
+Because a new major release typically has large new features that may not yet be tried by the user community, and because SDKs may lag in support of the new release, it is not expected that a new major release will immediately be designated as a LTS release, for example, 0.12.1 is not a LTS release.
+
+Each major release (0.11, 0.12, 0.13 etc.) will eventually have at least one minor release designated by the Aca-py maintainers as the LTS release, e.g. 0.11.1 for 0.11.x, 0.12.2 for 0.12.x (all references to future versions are hypothetical).
+
+After a LTS release is designated, minor releases will continue as normal. The Aca-py maintainers will decide whether a next release is another minor release, or a new major release. There is no predefined timing for next major version. The decision is typically based on semantic versioning considerations, such as whether API changes are needed or older capabilities need to be removed. Other considerations may also apply, for example significant upgrade steps may motivate a shift to a new major version.
+
+If a major release is not delivered for an extended period of time, the maintainers may designate a subsequent minor release as the next LTS release, for example if 0.11.1 is a LTS release and there is no need to increment to 0.12 for several quarters, the maintainers may decide to designate 0.11.1 as the next LTS release.
+
+## LTS 3rd digit patch releases
+
+For LTS releases, 3rd digit patch releases will be provided for bug and security fixes approximately every three months (may be more frequent if important fixes become available sooner, and may be deferred if there are no fixes to publish). Significant new features and other changes will not be included in 3rd digit patch releases, in order to ensure the stability of the LTS release and reduce the risk of functional regressions and bugs.
+
+## LTS release duration
+
+Once a *subsequent* LTS release is designated, users can expect 3rd digit patch releases to address critical bugs on the *prior* LTS release for approximately 9 more months. The maintainers will determine which fixes should to be backported to the latest LTS release, versus which fixes need to be further backported to the prior LTS release. 3rd digit patch releases should be expected less frequently for prior LTS releases, since only critical fixes will be published. The overlap period is intended to provide users a time window to upgrade their nodes, and any channel capabilities (if required).
+
+## LTS to LTS compatibility
+
+Features that are related to capabilities will remain available for two LTS releases, but may be removed in subsequent LTS releases. This will be documented in the [Supported RFCs and features](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md).
+
+## LTS and upgrade testing
+
+The Aca-py project expects to test single step upgrades (e.g. 0.11.1 to 0.11.2), and LTS to next-LTS upgrades (e.g. 0.11.1 to 0.12.2). Other upgrade paths will not be tested and are not guaranteed to work.
+
+
+# Prior art and alternatives
+[prior-art]: #prior-art
+
+While many open source projects provide LTS releases, there is no industry standard for LTS release approach. Projects use many different variants of LTS approaches to best suit their project's particular needs.
+
+This release strategy was based on the following opensource projects:
+
+- [Hyperledger Fabric](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md)
+- [NodeJS](https://nodejs.org/en/about/previous-releases)
+