Update the release lifecycle page to reflect current practices #1200
Conversation
|
Here is how it looks like after this change |
|
Some archeology:
|
fanquake
left a comment
fanquake
left a comment
There was a problem hiding this comment.
Concept ACK. I think this better aligns with what the project is currently doing.
We only make a difference between maintained versions and end of life versions. To reflect this practice, update the lifecycle page to drop the confusing EOM status. While at it, update the versioning and maintenance sections to more closely reflect the current practices of the project.
darosior
force-pushed
the
2511_drop_eom
branch
from
a8c98f3 to
70e2425
Compare
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
I guess I was one of the people that was confused by the previous description, but from what I can tell, it had been the modus operandi to put out minor releases for the the prior two branches around a new major release, e.g., we put out minor releases for 29.x and 28.x around the release of 30.0, and from what I understand that’ll be the last time there will be a release from the 28.x branch. If 28.x won’t get any further releases, wouldn’t it then be correct to classify 28.x as “unmaintained” at that point?
Wouldn’t it therefore make more sense to refer to the last two major branches as maintained instead of the last three?
In that sense, the “Maintenance End” column seems more relevant to me than the “End of Life” column.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
ACK 70e2425,
with a few optional suggestions.
| 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". |
There was a problem hiding this comment.
What do you think about:
- “Latest versions” instead of “past releases”
- Moving the example right after the rule it’s the example for
| 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. |
| 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 | ||
| 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. |
There was a problem hiding this comment.
Previously, this is referred to as “minor release”. I would recommend using the same term to refer to the same concept:
| 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. |
| 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 |
There was a problem hiding this comment.
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:
| 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 |
Given 30.x is the current release, I think the maintenance policy is something like:
I'm not sure about releases older than that? The release-process.md doc says EOL branches get a For a security bug that was fixed during the 30.x development cycle, and included in the 30.0 release, the disclosure timeline is:
As I understand it, even if medium/high severity bugs that get a covert backport into 29.x or 28.x, that doesn't affect the disclosure timeline. Perhaps we should provide a more concrete disclosure timeline/schedule somewhere, eg:
|
4 participants
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.