You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge #1200: Update the release lifecycle page to reflect current practices
84ddcf0 Update the release lifecycle page to reflect current practices (Antoine Poinsot)
Pull request description:
This updates the release lifecycle page to more closely reflect our actual releases. This started as an effort to drop the superfluous EOM status, but ended up as a rewrite of the Versioning, Maintenance and Schedule sections since all were depending on each other.
We only make a distinction between maintained and EOL versions. The EOM status adds unnecessary complexity and is misleading, so remove it.
This also cleans up the Versioning section, which was using three major heading (Versioning, Major releases and Maintenance releases) for a small amount of content all on the same topic of how the software we release is versioned. This also cleans up a redundant statement about backporting consensus changes and removes an unnecessary statement about the distinction between minor and major features for backports (which we don't even follow nowadays as far as i know).
Then we rewrite the maintenance version, which was making a distinction between "maintenance end" and "end of life" that we do not follow in practice, and overall makes it clearer and more concise. In this section i also remove some confused language about how we handle security fixes, which is not consistent with our practice, in favour of a general sentence that EOL versions do not receive security fixes and a link to our Security Advisories page which gives more details on this topic.
Wherever i touched i also updated the examples to use newer versions. In some cases i also switched from pointing to the exact major release (X.0) to the major version (X.Y) which is more accurate and also what we already do on the security advisories page.
ACKs for top commit:
murchandamus:
ACK 84ddcf0
willcl-ark:
LGTM. ACK 84ddcf0
sedited:
ACK 84ddcf0
Tree-SHA512: 16644e5d6572251a7721a28e099d1265b65af03505ad09b8ebff92602ef7f854888897913386d789a727b08bbf962fd0509eec4d0bb0f05deb5f88343dafe195
Copy file name to clipboardExpand all lines: _posts/en/pages/2016-01-15-lifecycle.md
+14-24Lines changed: 14 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,44 +16,33 @@ This document describes the life-cycle of the Bitcoin Core software package rele
16
16
17
17
Bitcoin Core releases are versioned as follows: MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc.
18
18
19
-
## Major releases
19
+
We aim to make a major release every 6 months. These will be numbered 29.0, 30.0 etc.
20
20
21
-
We aim to make a major release every 6-7 months.
22
-
23
-
These will be numbered 22.0, 23.0 etc.
24
-
25
-
## Maintenance releases
26
-
27
-
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.
28
-
29
-
Minor releases will be numbered 22.1, 22.2, 23.1, 23.2 etc.
21
+
We will provide minor ("maintenance") releases that fix bugs (security and otherwise) for each major release. These
22
+
will be numbered 29.3, 30.1, etc. We will not introduce major new features in maintenance releases (besides consensus
23
+
rules change, see below).
30
24
31
25
## Consensus rules
32
26
33
27
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.
34
28
35
29
## Maintenance period
36
30
37
-
We maintain the major versions until their "Maintenance End". We generally maintain the current and previous major release.
38
-
For example, if the current release is 23.0, then 22.0 is also considered maintained.
39
-
Once 24.0 is released, then 22.0 would be considered at its "Maintenance End".
40
-
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.
41
-
Once software has reached the "Maintenance End" period, it will only receive critical security fixes until the End-of-Life (EOL) date.
42
-
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.
43
-
Generally, it is recommended to run the latest maintenance release (point release) of the current or previous major version.
44
-
45
-
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.
31
+
We always maintain the latest three major versions. When a new major version is released, the oldest one falls out of
32
+
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
33
+
also considered maintained. Once 31.0 is released, 28.x becomes "End of Life". The threshold for backporting a change
34
+
to an older major version increases as it ages.
46
35
47
-
For example, major version 22.0 was released on 2021-09-13 and we provided maintenance fixes (point releases) until 2022-12-14.
48
-
Critical security issues would still be continued to be fixed until the EOL date of 2023-04-01.
49
-
However, to take advantage of bug fixes, you would have to upgrade to a later major version.
36
+
Major versions that are "End of Life" do not generally receive security fixes. For more about our policy on security
37
+
fixes, see our [security advisories][] page. We recommend running the latest maintenance release of the most recent
38
+
major version you are able to upgrade to.
50
39
51
40
## Schedule
52
41
53
42
Once EOL is reached, you will need to upgrade to a newer version.
54
43
55
-
| Version | Release Date |Maintenance End |End of Life |
0 commit comments