Add release cadence section to ensure a more predictable release cycle#21971
Add release cadence section to ensure a more predictable release cycle#21971ahrtr wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
|
||
| To make etcd's release cycles more predictable, the project targets **one major or minor version release per year**. | ||
|
|
||
| This cadence is intentional even in periods with few or no user-facing feature changes. A release may still include: |
There was a problem hiding this comment.
Minor release without user visible/impacting feature breaks user trust. We push toil to users to read documentation, execute upgrade and for what? Our own satisfaction that we wrote a blogpost and pushed binary.
Let's focus how we can encourage users to upgrade by building a roadmap of interesting features/performance improvement to draw interest of both users and contributors instead of just defining processes for processes sake.
There was a problem hiding this comment.
Minor release without user visible/impacting feature breaks user trust.
I don't agree. Did you read the items below? Also in practice, it is highly unlikely that there isn't any user-facing changes/features in 1 year duration.
building a roadmap
That's a separate topic.
I already see some positive feedback on this predictable release cadence proposal in #21605. Also I haven't never seen any negative feedback before I raised this PR.
Let's see other maintainers' opinion.
There was a problem hiding this comment.
I agree with Marek’s concern. A minor release should have clear user value, and we should build and maintain a well-defined roadmap instead of releasing purely for process reasons.
However, we should avoid v3.6 release cycle, where it took several years to publish a new minor release. By that point, main had diverged significantly from v3.5. It made maintaining supported release branches more challenging.
Maybe the schedule should be a regular checkpoint, not an automatic release trigger. We can use it to review the roadmap and the difference between main and supported release branches. If main does not have enough user-visible changes yet, and most fixes or small improvements can still be backported, we can explicitly decide to postpone the minor release, for example to 15 or 18 months.
However, I do not think we should postpone a minor release beyond two years.
There was a problem hiding this comment.
thx for the feedback. Updated. PTAL
Again, the motivation is to ensure a predictable release cadence. Nobody likes unpredictability.
Regarding the roadmap, we can discuss it separately.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted filessee 21 files with indirect coverage changes @@ Coverage Diff @@
## main #21971 +/- ##
==========================================
- Coverage 69.75% 69.72% -0.03%
==========================================
Files 449 449
Lines 38172 38172
==========================================
- Hits 26628 26617 -11
- Misses 10115 10126 +11
Partials 1429 1429 Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Signed-off-by: Benjamin Wang <benjamin.ahrtr@gmail.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, fuweid The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
4 participants
As we discussed in one of previous community meetings, also in #21605, we aim to make etcd’s release cycles more predictable. In this PR, I added one more section "Release cadence". PTAL
cc @fuweid @ivanvc @jberkus @serathius @siyuanfoundation @spzala