Add stable release policy (#685)

* add stable release policy

* add release series table

* point-release -> patch-release

* Apply suggestions from code review

Co-authored-by: Carlos Rodriguez <crodveg@yahoo.es>

* change LTS to be 1 year with potential extension

* Update RELEASES.md

Co-authored-by: Damian Nolan <damiannolan@gmail.com>

* Update RELEASES.md

Co-authored-by: Carlos Rodriguez <crodveg@yahoo.es>

* Update RELEASES.md

Co-authored-by: Carlos Rodriguez <carlos@interchain.io>

* update end of life table

Co-authored-by: Carlos Rodriguez <crodveg@yahoo.es>
Co-authored-by: Damian Nolan <damiannolan@gmail.com>
Co-authored-by: Carlos Rodriguez <carlos@interchain.io>

RELEASES.md

@@ -21,6 +21,45 @@ To summarize: **All our ibc-go releases allow chains to communicate successfully
 
 We ensure all major releases are supported by relayers ([hermes](https://github.com/informalsystems/ibc-rs), [rly](https://github.com/strangelove-ventures/relayer) and [ts-relayer](https://github.com/confio/ts-relayer) at the moment) which can relay between the new major release and older releases. We have no plans of upgrading to an IBC protocol specification v2.0, as this would be very disruptive to the ecosystem.
 
+## Stable Release Policy
+
+The beginning of a new major release series is marked by the release of a new major version. A major release series is comprised of all minor and patch releases made under the same major version number. The series continues to receive bug fixes (released as minor or patch releases) until it reaches end of life. The date when a major release series reaches end of life is determined by one of the two following methods:
+- If the next major release is made within the first 6 months, then the end of life date of the major release series is 1 year after its initial release. 
+- If the next major release is made 6 months after the initial release, then the end of life date of the major release series is 6 months after the release date of the next major release.
+
+For example, if the current major release series is v1 and was released on January 1st, 2022, then v1 will be supported at least until January 1st, 2023. If v2 is published on August 1st 2022, then v1's end of life will be March 1st, 2023. 
+
+Only the following major release series have a stable release status:
+
+|Release|End of Life Date|
+|-------|-------|
+|`v1.1.x`|July 01, 2022|
+|`v1.2.x`|July 01, 2022|
+|`v2.0.x`|February 01, 2023|
+
+**Note**: The v1 major release series will reach end of life 6 months after merging this policy. v2 will reach end of life one year after merging this policy. 
+
+### What pull requests will be included in stable patch-releases?
+
+Pull requests that fix bugs and add features that fall in the following categories:
+
+* **Severe regressions**.
+* Bugs that may cause **client applications** to be **largely unusable**.
+* Bugs that may cause **state corruption or data loss**.
+* Bugs that may directly or indirectly cause a **security vulnerability**.
+* Non-breaking features that are strongly requested by the community.
+* Non-breaking CLI improvements that are strongly requested by the community.
+
+### What pull requests will NOT be automatically included in stable patch-releases?
+
+As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases:
+
+* **State machine changes**, unless the previous behaviour would result in a consensus halt.
+* **Protobuf-breaking changes**.
+* **Client-breaking changes**, i.e. changes that prevent gRPC, HTTP and RPC clients to continue interacting with the node without any change.
+* **API-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
+* **CLI-breaking changes**, i.e. changes that require usage changes for CLI users.
+
 ## Graphics
 
 The decision tree above was generated with the following code: