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.
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.
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:
|
|
Concept ACK, seems like a nice improvement. I'd be happy to see this go in as-is after the above comments have been addressed, but I also took a stab at improving the general readability of the page a bit myself in willcl-ark@58bbe58, or in rendered form at https://github.com/willcl-ark/bitcoincore.org/blob/pr-1200/_posts/en/pages/2016-01-15-lifecycle.md, as I was reviewing the overall document. Feel free to take any changes from there that you like. |
darosior
force-pushed
the
2511_drop_eom
branch
from
70e2425 to
4b5bb81
Compare
|
@willcl-ark nice, thank you for doing this. I think this is mostly a desirable change, but a bit more than i'd like to do in this PR, and i have a couple small nits. Could you open it as a follow-up PR where i can leave a review comment? |
darosior
force-pushed
the
2511_drop_eom
branch
from
4b5bb81 to
058d0b8
Compare
|
Addressed comments, fixed CI (update now-outdated links to deleted section), and made one tiny modification in the introduction after a second read. |
darosior
force-pushed
the
2511_drop_eom
branch
from
058d0b8 to
568ca0a
Compare
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
568ca0a to
84ddcf0
Compare
6 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.