Skip to content

Update the release lifecycle page to reflect current practices #1200

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

Open
darosior wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update the release lifecycle page to reflect current practices #1200

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
48 changes: 24 additions & 24 deletions _includes/posts/maintenance-table.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,24 +1,24 @@
| 31.x | TBA* | after v33.0 | after v34.0 |
| 30.x | 2025-10-10 | after v32.0 | after v33.0 |
| 29.x | 2025-04-14 | after v31.0 | after v32.0 |
| 28.x | 2024-10-02 | 2025-10-10 | after v31.0 |
| 27.x | 2024-04-16 | 2025-04-14 | 2025-10-10 |
| 26.x | 2023-12-06 | 2024-10-02 | 2025-04-14 |
| 25.x | 2023-05-18 | 2024-04-16 | 2024-10-02 |
| 24.x | 2022-11-24 | 2023-12-12 | 2024-04-02 |
| 23.x | 2022-04-25 | 2023-05-18 | 2023-12-01 |
| 22.x | 2021-09-13 | 2022-12-14 | 2023-04-01 |
| 0.21.x | 2021-01-15 | 2022-04-25 | 2022-10-01 |
| 0.20.x | 2020-06-03 | 2021-09-13 | 2022-02-01 |
| 0.19.x | 2019-11-24 | 2021-01-15 | 2021-08-01 |
| 0.18.x | 2019-05-02 | 2020-06-03 | 2021-02-01 |
| 0.17.x | 2018-10-03 | 2019-11-24 | 2020-08-01 |
| 0.16.x | 2018-02-26 | 2019-05-02 | 2020-02-01 |
| 0.15.x | 2017-09-15 | 2018-10-03 | 2019-08-01 |
| 0.14.x | 2017-03-08 | 2018-02-26 | 2019-02-01 |
| 0.13.x | 2016-08-23 | 2017-09-15 | 2018-08-01 |
| 0.12.x | 2016-02-23 | 2017-03-31 | 2018-02-28 |
| 0.11.x | 2015-07-12 | 2016-08-23 | 2017-08-01 |
| 0.10.x | 2015-02-16 | 2016-02-29 | 2017-02-28 |
| 0.9.x | 2014-03-19 | 2015-06-16 | 2016-02-28 |
| 0.8.x | 2013-02-19 | 2014-03-19 | 2015-12-31 |
| 31.x | TBA* | after v34.0 |
| 30.x | 2025-10-10 | after v33.0 |
| 29.x | 2025-04-14 | after v32.0 |
| 28.x | 2024-10-02 | after v31.0 |
| 27.x | 2024-04-16 | 2025-10-10 |
| 26.x | 2023-12-06 | 2025-04-14 |
| 25.x | 2023-05-18 | 2024-10-02 |
| 24.x | 2022-11-24 | 2024-04-02 |
| 23.x | 2022-04-25 | 2023-12-01 |
| 22.x | 2021-09-13 | 2023-04-01 |
| 0.21.x | 2021-01-15 | 2022-10-01 |
| 0.20.x | 2020-06-03 | 2022-02-01 |
| 0.19.x | 2019-11-24 | 2021-08-01 |
| 0.18.x | 2019-05-02 | 2021-02-01 |
| 0.17.x | 2018-10-03 | 2020-08-01 |
| 0.16.x | 2018-02-26 | 2020-02-01 |
| 0.15.x | 2017-09-15 | 2019-08-01 |
| 0.14.x | 2017-03-08 | 2019-02-01 |
| 0.13.x | 2016-08-23 | 2018-08-01 |
| 0.12.x | 2016-02-23 | 2018-02-28 |
| 0.11.x | 2015-07-12 | 2017-08-01 |
| 0.10.x | 2015-02-16 | 2017-02-28 |
| 0.9.x | 2014-03-19 | 2016-02-28 |
| 0.8.x | 2013-02-19 | 2015-12-31 |
37 changes: 13 additions & 24 deletions _posts/en/pages/2016-01-15-lifecycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,44 +16,33 @@ This document describes the life-cycle of the Bitcoin Core software package rele

Bitcoin Core releases are versioned as follows: MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc.

## Major releases
We aim to make a major release every 6 months. These will be numbered 29.0, 30.0 etc.

We aim to make a major release every 6-7 months.

These will be numbered 22.0, 23.0 etc.

## Maintenance releases

We will provide maintenance "minor releases" that fix bugs within the major releases. As a general rule we do not introduce major new features in a maintenance release (except for consensus rules). However, we may add minor features where necessary, and we will back-port consensus rule changes such as soft forks.

Minor releases will be numbered 22.1, 22.2, 23.1, 23.2 etc.
We will provide maintenance minor releases that fix bugs (security and otherwise) for each major release. These
will be numbered 29.3, 30.1, etc. We will not introduce major new features in maintenance releases (besides consensus
rules change, see below).

## Consensus rules

Proposals to change consensus rules are always shipped first in maintenance versions such as 22.2, 23.1 etc. This makes it easier for enterprise users to assess and test the proposal because of its smaller changeset compared to a major release. It also allows users who follow a more conservative upgrade path to adopt consensus rule changes in a more timely manner.

## Maintenance period

We maintain the major versions until their "Maintenance End". We generally maintain the current and previous major release.
For example, if the current release is 23.0, then 22.0 is also considered maintained.
Once 24.0 is released, then 22.0 would be considered at its "Maintenance End".
As a major release ages, issues have to be increasingly critical to be backported to it, and an increasing amount or severity of issues is required to warrant a new minor release.
Once software has reached the "Maintenance End" period, it will only receive critical security fixes until the End-of-Life (EOL) date.
After EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis.
Generally, it is recommended to run the latest maintenance release (point release) of the current or previous major version.

Please note that minor versions get bugfixes, translation updates, and soft forks. Translation on [Transifex][bitcoin-transifex-link] is only open for the last two major releases.
We always maintain the past three major versions released. Once a major version falls outside that window, it becomes
"End of Life". The threshold for backporting a change to a past major version increases as it ages. For example, if the
last major release is 30.0, then 29.x and 28.x are also considered maintained. Once 31.0 is released, then 28.x becomes
"End of Life".
Comment on lines +31 to +34
Copy link
Contributor

@murchandamus murchandamus Dec 11, 2025

Choose a reason for hiding this comment

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

What do you think about:

  • “Latest versions” instead of “past releases”
  • Moving the example right after the rule it’s the example for
Suggested change
We always maintain the past three major versions released. Once a major version falls outside that window, it becomes
"End of Life". The threshold for backporting a change to a past major version increases as it ages. For example, if the
last major release is 30.0, then 29.x and 28.x are also considered maintained. Once 31.0 is released, then 28.x becomes
"End of Life".
We always maintain the latest three major versions. When a new major version is released, the oldest one falls out of the maintenance window and becomes
"End of Life". For example, if the
last major release is 30.0, then 29.x and 28.x are also considered maintained. Once 31.0 is released, 28.x becomes
"End of Life".
The threshold for backporting a change to an older major version increases as it ages.


For example, major version 22.0 was released on 2021-09-13 and we provided maintenance fixes (point releases) until 2022-12-14.
Critical security issues would still be continued to be fixed until the EOL date of 2023-04-01.
However, to take advantage of bug fixes, you would have to upgrade to a later major version.
Major versions that are "End of Life" do not, as a general rule, receive security fixes. For more about our policy on
Copy link
Contributor

@murchandamus murchandamus Dec 11, 2025

Choose a reason for hiding this comment

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

I don’t think it’s necessary to point out that we might make an exception and do more work than we generally intend to:

Suggested change
Major versions that are "End of Life" do not, as a general rule, receive security fixes. For more about our policy on
Major versions that are "End of Life" do not receive security fixes. For more about our policy on

security fixes, see our [security advisories](/en/security-advisories/) page. We recommend running the latest
maintenance release (point release) of the most recent major version you are able to upgrade to.
Copy link
Contributor

@murchandamus murchandamus Dec 11, 2025

Choose a reason for hiding this comment

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

Previously, this is referred to as “minor release”. I would recommend using the same term to refer to the same concept:

Suggested change
maintenance release (point release) of the most recent major version you are able to upgrade to.
maintenance release (minor release) of the most recent major version you are able to upgrade to.


## Schedule

Once EOL is reached, you will need to upgrade to a newer version.

| Version | Release Date | Maintenance End | End of Life |
|---------|--------------|-----------------|-------------|
| Version | Release Date | End of Life |
|---------|--------------|-------------|
{% include posts/maintenance-table.md %}

\* _We aim to make a major release every 6-7 months_
Expand Down