Support policy for CometBFT releases #590
Replies: 5 comments 4 replies
-
|
An alternative approach mentioned by @alexanderbez and @hdevalence is to only offer feature updates to the two latest versions, and perhaps in special cases (like with the v0.34 release) offer only critical/security fixes for some period of time (this would effectively be our "LTS" pledge to users). |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Since it's our biggest paying customer, we want to support whatever version Cosmos Hub is on as our "LTS". 👍 for supporting the two latest versions. The idea is that Cosmos Hub will eventually use the |
Beta Was this translation helpful? Give feedback.
-
|
We are planning to have these phases in the Support lifecycle for each major release of Comet, going through the following stages:
|
Beta Was this translation helpful? Give feedback.
-
|
I love the idea of LTS, it will make life so much easier on multiple fronts. However, can we choose an existing framework instead of reinventing parts? For example, Ubuntu has: Translated this to our situation, we only need LTS support for a few releases and a promise that new beta versions are security-supported. Also, based on our development speed, we only need LTS for a shorter amount of time. I wanted to add the Debian LTS support model for comparison, but they essentially outsourced it. It's more of a security patch backport support than anything else. (5 years) The Linux kernel support is also much simpler for the core team. They have designated LTS versions released and each of them has its support agreement so new LTS versions can be fine-tuned (it seems currently they're on a 5-6-year schedule depending on if you count from the start of development or the start of a first stable release.) Super-long-term support is outsourced. In our case, I guess we can take on super-long-term support as a paid contract. (Like upgrading very old networks.) The NodeJS Release Group defines Current/LTS/Maintenance releases, supporting up to the latest-2 major releases. They also have a different shelf-life: about 1-2-2 years, covering a total of 5 years of support for a specific version. So instead of a specific version designated as LTS, ALL versions start as current, then they transition to LTS, and then maintenance. Their release policy is straightforward too. Or choose a project that's closer to us like the Go programming language release schedule/support, because that will have an impact on our codebase. TBH, the Go release support is painful, but I find it keeps the developers on their toes about security and keeping up with the ever-changing world. Which I find leads to better code hygiene among production environments too because they are forced to keep their applications up-to-date. In our security-conscious world, that's inevitable. The LTS support model will make application life easier, but it doesn't resolve operational maintenance needs: a security patch-related upgrade will still cause network upgrades, possibly downtimes, and overall, ops work. |
Beta Was this translation helpful? Give feedback.
-
|
We originally did consider the possibility of adopting an LTS strategy, but after much consideration I don't think it really works in our context. Some issues I can remember off the top of my head:
There could be other reasons that aren't coming to mind now, and I'll add them if/when I think of them. This approach we're outlining here effectively provides the "building blocks" of an LTS strategy (i.e. LTS is not incompatible with the approach we're suggesting). The approach we're suggesting, however, does give us more flexibility to, over the next year, learn more about what kind of release cadence we can push and whether adopting a more constrained LTS strategy in 2024 or 2025 makes sense. |
Beta Was this translation helpful? Give feedback.
-
ProposalModesAssuming the different modes (similar to that Andy described above):
Support policy proposal0.34
0.37
0.38
v1
v2 - this schedule is subject to change
DiagramFor a quick overview here's a diagram: |
Beta Was this translation helpful? Give feedback.
-
|
As published recently on @cometBFT X account, here is a recap of the current support policy and End of Life (EOL) schedule for CometBFT. This covers the period 2024 - 2026, and versions 0.34, 0.37, 0.38, and v1. Support PolicyCometBFT Release StatesThese are the different states of any CometBFT release:
The Role of Experimental BranchesThe role of
End of Life (EOL) ScheduleThe current EOL schedule, as discussed at the community call on Aug 1 '24 is described below. OverviewSummary
|
Beta Was this translation helpful? Give feedback.
-
|
For completeness, describing here also the decision tree for backporting. Backporting Decision TreeBackporting a specific PR to a release or branch of CometBFT depends on two basic factors:
For the Comet team to decide on backporting, below we describe the decision tree we use intuitively for every PR. EOLIf a version is marked as EOL, then:
HCF
BF
NF
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are in the process of defining a support policy for CometBFT releases. Ultimately we need to balance a few major tensions:
The more releases we have to maintain, the fewer new substantial features/changes/improvements we can produce with our limited resources.
A proposal that has come up recently is to adopt an Ubuntu-like LTS (long term support) strategy, where we dub specific releases as "LTS releases" for which we will provide bug/security fixes for a significant period of time (e.g. 2 years), and other major releases we will only support for a much shorter period of time (e.g. 6, 8 or 10 months, but < 1 year).
Our current thinking is that we want to have our v0.34 release as our first LTS release, and we will pick a subsequent release (perhaps v0.39/v0.40/v1.0, pending discussion in #357) as our next LTS release, but wanted to open this up to the community for feedback.
We're aiming to make a decision here during Q2 of 2023.
Beta Was this translation helpful? Give feedback.
All reactions