Skip to content
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.

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

Release schedule for 23.0 #22969

Closed
laanwj opened this issue Sep 14, 2021 · 11 comments
Closed

Release schedule for 23.0 #22969

laanwj opened this issue Sep 14, 2021 · 11 comments
Milestone

Comments

@laanwj
Copy link
Member

laanwj commented Sep 14, 2021

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 ✔️

  • 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 ✔️

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

2022-03-01 ✔️

  • 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 ✔️

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

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

@JeremyRubin
Copy link
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.

@maflcko
Copy link
Member

maflcko commented Dec 21, 2021

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
Copy link
Contributor

jonatack commented Dec 21, 2021

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
Copy link
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
Copy link
Member

hebasto commented Jan 26, 2022

 ## 2022-02-02 :construction: 
+- Update translations in the master branch
 - 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

See #24172.

@laanwj
Copy link
Member Author

laanwj commented Feb 3, 2022

  • 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
Copy link
Member Author

laanwj commented Feb 3, 2022

PR for translations freeze is open: #24250

@laanwj
Copy link
Member Author

laanwj commented Feb 3, 2022

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

@hebasto
Copy link
Member

hebasto commented Feb 18, 2022

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

laanwj added a commit to bitcoin-core/gui that referenced this issue Feb 22, 2022
c515829 qt: Update translation source file (Hennadii Stepanov)

Pull request description:

  As the part of the v23.0 [release process](bitcoin/bitcoin#22969) this PR updates translation source file, `src/qt/locale/bitcoin_en.xlf`.

  The following changes are reflected in this PR:
  - small string changes from #509
  - internal technical details from bitcoin/bitcoin#22151

ACKs for top commit:
  laanwj:
    ACK c515829

Tree-SHA512: 2cf08f5b356dca25f99b0342645db5253eab0854796cf44fa52f8a6cf28f6d3f973e21589e0f9d3fef40a1b21b3f0aee00c9ca0897109a1967f9ef3320dd508f
@bitcoin bitcoin deleted a comment from BITCACH Mar 2, 2022
fanquake added a commit to bitcoin-core/gui that referenced this issue Mar 7, 2022
956f732 build: Bump minimum Qt version to 5.11.3 (Hennadii Stepanov)
e22d10b ci: Switch from bionic to buster (Hennadii Stepanov)

Pull request description:

  The current minimum Qt version is 5.9.5 which has been set in bitcoin/bitcoin#21286.

  Distro support:
  - centos 7 -- unsupported since bitcoin/bitcoin#23511
  - centos 8 -- [5.15.2](http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/qt5-qtbase-5.15.2-3.el8.x86_64.rpm)
  - buster -- [5.11.3](https://packages.debian.org/buster/libqt5core5a)
  - bullseye  -- [5.15.2](https://packages.debian.org/bullseye/libqt5core5a)
  - _bionic_ -- [5.9.5](https://packages.ubuntu.com/bionic/libqt5core5a)
  - focal -- [5.12.8](https://packages.ubuntu.com/focal/libqt5core5a)

  As another Ubuntu LTS is coming soon, it seems unreasonable to stick to Qt 5.9 which support [ended](https://www.qt.io/blog/2017/06/07/renewed-qt-support-services) on 2020-05-31. Anyway, it's still possible to build Bitcoin Core GUI with depends on bionic system.

  Bumping the minimum Qt version allows to make code safer and more reliable, e.g.:
  - functor-parameter overload of [`QMetaObject::invokeMethod`](https://doc.qt.io/qt-5/qmetaobject.html#invokeMethod-4)
  - fixed https://bugreports.qt.io/browse/QTBUG-10907

  An example of the patch using the functor-overload of `QMetaObject::invokeMethod`:
  ```diff
  --- a/src/qt/walletmodel.cpp
  +++ b/src/qt/walletmodel.cpp
  @@ -349,7 +349,7 @@ bool WalletModel::changePassphrase(const SecureString &oldPass, const SecureStri
   static void NotifyUnload(WalletModel* walletModel)
   {
       qDebug() << "NotifyUnload";
  -    bool invoked = QMetaObject::invokeMethod(walletModel, "unload");
  +    bool invoked = QMetaObject::invokeMethod(walletModel, &WalletModel::unload);
       assert(invoked);
   }

  ```
  It uses the same new syntax as signal-slot connection with compile-time check. Also see bitcoin/bitcoin#16348.

  This PR is intended to be merged early [after](bitcoin/bitcoin#22969) branching `23.x` off.

ACKs for top commit:
  MarcoFalke:
    cr ACK 956f732
  fanquake:
    ACK 956f732

Tree-SHA512: 3d652bcdcd990ce785ad412ed70234d4f27743895e535a53ed44b35d4afc3052e066c4c84f417e30bc53d0a3dd9ebed62444c57b7c765cb1e9aa687fbf866877
@laanwj
Copy link
Member Author

laanwj commented Mar 8, 2022

I created a testing issue for the RCs: #24501

@laanwj
Copy link
Member Author

laanwj commented Mar 8, 2022

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

@fanquake fanquake unpinned this issue Apr 25, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Apr 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants
@laanwj @fanquake @JeremyRubin @jonatack @maflcko @hebasto and others