Release schedule for 23.0

laanwj commented at 8:25 am on September 14, 2021: member

Here is a proposed release schedule for 23.0, the next major release of Bitcoin Core. I’ve aimed for a release 7 months after the (-final) release of the last (#20851), 7 instead of 6 months (as is customaryl) to not have a crunch time so soon after the new year.

2022-02-02 :heavy_check_mark:

Open Transifex translations for 23.0
Soft translation string freeze (no large or unnecessary string changes until release)
Finalize and close translations for 0.21

2022-02-15 :heavy_check_mark:

Feature freeze (bug fixes only until release)
Translation string freeze (no more source language changes until release)

2022-03-01 :heavy_check_mark:

Split off 23.x branch from master
Start RC cycle, tag and release 23.0rc1
Start merging for 24.x on master branch

2022-04-01 :heavy_check_mark:

Release 23.0 (actual release date 2022-04-26)

If any specific dates or timeframes are a problem for you, let me know.

laanwj added the label Build system on Sep 14, 2021

laanwj added this to the milestone 23.0 on Sep 14, 2021

laanwj pinned this on Sep 14, 2021

fanquake deleted a comment on Dec 10, 2021

JeremyRubin commented at 9:10 pm on December 20, 2021: contributor

based on: #23810 (comment)

would it be possible to define a ‘conflict-annoying refactor’ period that is after feature freeze and before split off master?

This helps aid a workflow where features don’t get rebase-helled until at least after the feature work period, and also makes it easier to have to ‘rebase once’ after the style change period elapses.

MarcoFalke commented at 12:01 pm on December 21, 2021: member

The “bug fix only” period in the past has certainly been used to merge other stuff, like documentation changes, test changes, or sometimes even uncontroversial refactors that are unlikely to break something. Maybe it is best to discuss on a case-by-case basis if something would be suitable for merge then? (re #23810: Telling from the comments, this is certainly controversial, so seems not the right fit)

jonatack commented at 1:20 pm on December 21, 2021: member

would it be possible to define a ‘conflict-annoying refactor’ period that is after feature freeze and before split off master?

This helps aid a workflow where features don’t get rebase-helled until at least after the feature work period, and also makes it easier to have to ‘rebase once’ after the style change period elapses.

If this were to be done, maybe some time after a successful release toward the start of a release cycle. Rationale: avoidance of bugs in a release > avoidance of rebase annoyance.

JeremyRubin commented at 5:05 pm on December 21, 2021: contributor

i think a good time for that could be immediately after release branch splits from master? That way there isn’t a dead month after split off?

hebasto commented at 9:56 pm on January 26, 2022: member

0 ## 2022-02-02 :construction: 
1+- Update translations in the master branch
2 - Open Transifex translations for 23.0
3 - Soft translation string freeze (no large or unnecessary string changes until release)
4 - Finalize and close translations for 0.21

See #24172.

laanwj commented at 11:01 am on February 3, 2022: member

Update translations in the master branch @hebasto Wouldn’t it be better to do this before the branch-off, instead of before opening 0.23 translations? It means master will have at least some up-to-date translations, instead of stale ones from the last major release.

laanwj commented at 12:29 pm on February 3, 2022: member

PR for translations freeze is open: #24250

laanwj commented at 6:38 pm on February 3, 2022: member

Larger release process items that need to be done (preferably before the branch-off, so in the month of Februari):

Update hardcoded seeds, see this pull request for an example. [last update was #20237 for 0.21]
- PR #24417
Update src/chainparams.cpp m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead (see this for information on how to calculate them). [last update was #22499 for 22.0]
- PR #24418
Update src/chainparams.cpp chainTxData with statistics about the transaction count and rate. Use the output of the getchaintxstats RPC, see this pull request for an example. Reviewers can verify the results by running getchaintxstats <window_block_count> <window_final_block_hash> with the window_block_count and window_final_block_hash from your output. [last update was #22499 for 22.0]
- PR #24418
Update src/chainparams.cpp nMinimumChainWork and defaultAssumeValid (and the block height comment) with information from the getblockheader (and getblockhash) RPCs. [last update was #22499 for 22.0]
- PR #24418
Update bips.md to account for changes since the last release (don’t forget to bump the version number on the first line).
- PR #24420
Update translations from transifex (last minute)
- PR #24451

hebasto commented at 10:22 am on February 18, 2022: member

Post-translation-string-freeze PR for a final translation source file update is open: #24377.

laanwj referenced this in commit c44e734dca on Feb 22, 2022

fanquake deleted a comment on Mar 2, 2022

fanquake referenced this in commit c9ed9927bb on Mar 7, 2022

laanwj commented at 11:01 am on March 8, 2022: member

I created a testing issue for the RCs: #24501

laanwj commented at 3:46 pm on March 8, 2022: member

@hebasto updated his workflow guide for guix buliding to 23.0: https://gist.github.com/hebasto/7293726cbfcd0b58e1cfd5418316cee3

fanquake closed this on Apr 25, 2022

fanquake unpinned this on Apr 25, 2022

DrahtBot locked this on Apr 26, 2023

Release schedule for 23.0 #22969

2022-02-02 :heavy_check_mark:

2022-02-15 :heavy_check_mark:

2022-03-01 :heavy_check_mark:

2022-04-01 :heavy_check_mark: