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
Comments
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. |
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) |
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. |
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? |
## 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. |
@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. |
PR for translations freeze is open: #24250 |
Larger release process items that need to be done (preferably before the branch-off, so in the month of Februari):
|
Post-translation-string-freeze PR for a final translation source file update is open: #24377. |
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
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
I created a testing issue for the RCs: #24501 |
@hebasto updated his workflow guide for guix buliding to 23.0: https://gist.github.com/hebasto/7293726cbfcd0b58e1cfd5418316cee3 |
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 ✔️
2022-02-15 ✔️
2022-03-01 ✔️
23.x
branch frommaster
23.0rc1
master
branch2022-04-01 ✔️
If any specific dates or timeframes are a problem for you, let me know.
The text was updated successfully, but these errors were encountered: