Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add stable release policy #685

Merged
merged 15 commits into from
Feb 1, 2022
Merged

Add stable release policy #685

Changes from 10 commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
e7362bc
add stable release policy
colin-axner Jan 5, 2022
dc36bee
add release series table
colin-axner Jan 5, 2022
f2c60b6
point-release -> patch-release
colin-axner Jan 5, 2022
92d36c6
Apply suggestions from code review
colin-axner Jan 7, 2022
1ac8847
Merge branch 'main' into colin/671-lts-policy
colin-axner Jan 7, 2022
7267dbb
Merge branch 'main' into colin/671-lts-policy
colin-axner Jan 7, 2022
41a8062
change LTS to be 1 year with potential extension
colin-axner Jan 7, 2022
8f8c65d
Merge branch 'main' into colin/671-lts-policy
crodriguezvega Jan 8, 2022
6a3228c
Update RELEASES.md
colin-axner Jan 12, 2022
892be6a
Merge branch 'main' into colin/671-lts-policy
colin-axner Jan 12, 2022
ebd2521
Update RELEASES.md
colin-axner Jan 13, 2022
5ea8c11
Update RELEASES.md
colin-axner Jan 14, 2022
1d53124
Merge branch 'main' into colin/671-lts-policy
colin-axner Jan 14, 2022
28f9107
update end of life table
colin-axner Feb 1, 2022
1d46cf7
Merge branch 'main' into colin/671-lts-policy
colin-axner Feb 1, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions RELEASES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,41 @@ 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

A major release series continues to receive bug fixes (released as a patch release) until it reaches end of life. A major release series reaches end of life 1 year after its initial release. An extension to the end of life date is made if the next major release is not made for 6 months. In this situation, the end of life is the date of publication for the next major release plus 6 months.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when we talk here about major release we refer to all the release series in, for example, v1 (i.e. 1.0.x, 1.1.x, etc), right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a sentence you'd like me to add clarifying this?

Copy link
Contributor

@crodriguezvega crodriguezvega Jan 12, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could there be some confusion here with the term major release? For example:

  • v1.0.x is created on January 1st 2021.
  • v1.1.x is created on July 1st 2021.
  • v2.0.x is created on February 1st 2022.
    Then v1.0.x reaches end of life on January 1st, 2022 and v1.1.x reaches end of life August 1st , 2022, right? And if we find a security vulnerability in v1.1.x and we need to cut v1.2.x in April 1st, 2022, will the v1.2.x release series reach end of life as well in August 1st, 2022?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are getting lost in the weeds. Lets think about the user perspective and why they want support for minor vs major releases.

Updating to a different minor release implies a coordinated chain upgrade.
Updating to a different major release implies a code upgrade + coordinated chain upgrade.

We want to give developers ample time to update their code to the next version so we don't disrupt their workflow.

The 6 month policy is basically saying, you have 6 months to update your code once the next major release is done. If we release the next major release very fast, you have a little more than 6 months.

So once v2 is released, the 6 month timer should be applied to all existing release lines

How about this. We define a release line as either major or minor. When the next major release hasn't been made, the end of life of the release line is 1 year (with the possibility of extension). When the next major release has already been made, the end of life is 6 months.

So in the above example, the end of life for v1.2.x is October 1st, 2022

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible this policy is going to force us to maintain release lines for a long time, but there's only one way to find out 🙂

Thoughts?

Copy link
Contributor

@crodriguezvega crodriguezvega Jan 14, 2022 •
edited by colin-axner
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of these changes?

Suggested change
A major release series continues to receive bug fixes (released as a patch release) until it reaches end of life. A major release series reaches end of life 1 year after its initial release. An extension to the end of life date is made if the next major release is not made for 6 months. In this situation, the end of life is the date of publication for the next major release plus 6 months.
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I guess the table needs to be updated then? Should v1 reach end of life a year from merging this pr?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we say maybe that v1 gets 6 months and v2 one year?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea that sounds good to me! I don't really expect many folks to be on v1 since many are going from stargate -> v2 since v1 wasn't out by itself for too long


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if we didn't make a new major release (for example, v2) after the previous one (for example, v1) for longer than a year, does that mean that the previous major release (v1) reaches end of life the moment the new major release is released?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, v1 would reach end of life 6 months after v2 is released


Only the following major release series have a stable release status:

|Release|End of Life Date|
|-------|-------|
|`v1.1.x`|September 03, 2022|
|`v1.2.x`|September 10, 2022|
|`v2.0.x`|November 09, 2022|

### 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:
Expand Down