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.

Sign up for GitHub

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

Jump to bottom

Release schedule for 0.21.0 #18947

Closed
laanwj opened this issue May 11, 2020 · 13 comments
Closed

Release schedule for 0.21.0 #18947

laanwj opened this issue May 11, 2020 · 13 comments
Milestone
0.21.0

Comments

@laanwj
Copy link
Member

laanwj commented May 11, 2020 •
edited

Here is a proposed release schedule for 0.21.0, the next major release of Bitcoin Core. Like for previous major releases I've aimed for a release 6 months after the last (#17432).

2020-10-01 ✔️

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

2020-10-15 ✔️

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

2020-11-01 ✔️

  • Split off 0.21 branch from master
  • Start RC cycle, tag and release 0.21.0rc1
  • Start merging for 0.22 on master branch

2021-01-14 ✔️

  • Release 0.21.0 final

If any specific dates or timeframes are a problem for you, let me know.
@laanwj laanwj added this to the 0.21.0 milestone May 11, 2020
@maflcko maflcko mentioned this issue May 12, 2020
Merged
@laanwj laanwj pinned this issue Jun 2, 2020
@laanwj laanwj changed the title Release schedule for 0.21.0 (preliminary) Release schedule for 0.21.0 Jun 2, 2020
@maflcko maflcko mentioned this issue Jun 14, 2020
Closed
@fanquake fanquake mentioned this issue Jun 17, 2020
Merged
laanwj added a commit that referenced this issue Jun 22, 2020
@laanwj
Merge #19305: doc: add C++17 release note for 0.21.0
e3fa3c7 
f1d21ef doc: add C++17 release note for 0.21.0 (fanquake)

Pull request description:

  TLDR: Mention that the codebase is now compatible with C++17, and that the
  intention is to require C++17 starting with 0.22.0.

  Following some discussion with Cory/Carl, and in #16684, I think this is the next step in the C++17 migration.

  While #16684 mentions a gitian/Guix release with C++17, it's not yet clear how that would be done. Are we just going to pass `--enable-c++17` in gitian/Guix?. Are we changing our default in configure.ac?

  According to the [last comment](#16684 (comment)) in #16684, we wouldn't be changing anything in depends:
  > No, everything (including depends) will stay at C++11.

  However I don't think we want to be mixing C++11 built dependencies, with a C++17 built bitcoind, if there is any potential for compatibility issues.

  Instead, I'd suggest we build the 0.21.0 release as C++11, and do a complete switch to C++17 for 0.22.0. Also, if we actually wanted to use C++17 in depends for 0.21.0, we couldn't without breaking C++11 compat (Qt). See below.

  Here is a potential timeline/TODOs for the migration:

  Potential Timeline
  * 17 / 6 / 2020 - Today
  * Some time prior to split-off:
      * Confirm that compiling with C++17 works.
      * Confirm that C++11 compatibility has not been broken.
  * 1 / 11 / 2020
      * [0.21.0 split off happens](#18947).
  * 2 / 11 / 2020
      * Merge an "incompatible with C++11" change into master.
      * Switch configure to use C++17 mode by default.
      * Update minimum compiler requirements. At least:
          * Clang 5: https://clang.llvm.org/cxx_status.html#cxx17
          * GCC 7: https://gcc.gnu.org/projects/cxx-status.html#cxx17
              * While GCC has some support from 5, it seems a more complete support landed in GCC 7.
              * https://gcc.gnu.org/gcc-7/changes.html#cxx
      * Switch depends packages to use C++17 where applicable.
      * Bump Qt from 5.9.x (no c++17 mode) to, likely, 5.15.x (LTS).
      * Drop support for macOS < 10.14.x
          * The c++ dylib shipped with macOS [doesn't support c++17, prior to macOS 10.14](#16684 (comment)).
          * Building Qt 5.12 or 5.15 in C++17 mode will also require a minimum macOS deployment target of 10.14. https://codereview.qt-project.org/c/qt/qtbase/+/283832.
      * Begin merging PRs like #19183 and #19245.
          * I've left some comments in #19183 if the macOS runtime issue interests anyone.
  * 3 / 12 / 2020
      * 0.21.0 released.
      * Built as C++11.
      * Contains warning in release notes that compiling 0.22.0 will require C++17.
  * 3 / 6 / 2021
      * 0.22.0 released.
      * Full of C++17 code.

  One thing worth noting, is that we cannot bump our Qt to a newer LTS for 0.21.0, without breaking C++11 compatibility. Qt 5.12 is not compilable in C++11 mode, as the project has started using C++14 features throughout at least the macOS portions of it's codebase, and seemingly "forgotten" that the release is meant to be C++11 compatible.
  Upstream bug here: https://bugreports.qt.io/browse/QTBUG-77310.
  > Building Qt requires C+11, at a minimum, but in practice we use later features, usually under a feature define, or with a fallback of some kind. On platforms that support > C11, we've (apparently) not considered the fallback necessary, under the assumption C+14 is always available.

ACKs for top commit:
  MarcoFalke:
    ACK f1d21ef can't hurt to give an advance warning
  Sjors:
    ACK f1d21ef
  laanwj:
    ACK f1d21ef
  theStack:
    ACK f1d21ef

Tree-SHA512: 706baceb07d9584783ba6e437cdf447531c20f586285b9797edc21f3adb1e9d386059d1c543c70eb298d0f8e555dafb6682a55d35c5836979fc12132e8ba06f5
@jonatack jonatack mentioned this issue Aug 5, 2020
Closed
@hebasto hebasto mentioned this issue Sep 12, 2020
Merged
@maflcko maflcko mentioned this issue Sep 22, 2020
Closed
@jnewbery jnewbery mentioned this issue Sep 30, 2020
Closed
@laanwj laanwj mentioned this issue Oct 1, 2020
Merged
fanquake added a commit that referenced this issue Oct 2, 2020
@fanquake
Merge #20058: Update transifex slug for 0.21
69a7380 
7532c9a qt: Periodic translations update (Wladimir J. van der Laan)
598e3b1 tx: Update transifex slug for 0.21 (Wladimir J. van der Laan)

Pull request description:

  Update transifex slug for 0.21 (as part of #18947), and do a periodic translations update.

ACKs for top commit:
  fanquake:
    ACK 7532c9a

Tree-SHA512: 7e396c9a7bcf69088ec89b604332b44cfc2f1949665a7d464ad7cd1c6156cd32ca4a6f7e0b70e4782966f0904c82c4c9286b25ada98052adeaf97e1f408489f6
@hebasto hebasto mentioned this issue Oct 8, 2020
Closed
@Bosch-0 Bosch-0 mentioned this issue Oct 12, 2020
Closed
@andronoob
Copy link

andronoob commented Oct 17, 2020 •
edited

Sorry, I might be too late for the translation string freeze deadline. But there's still a possibly misleading UI text:

bitcoin/src/qt/addressbookpage.cpp

Line 109 in b3527fd

ui->labelExplanation->setText(tr("These are your Bitcoin addresses for receiving payments. Use the 'Create new receiving address' button in the receive tab to create new addresses.\nSigning is only possible with addresses of the type 'legacy'."));

I think "Signing" here means "message sign/verify", doesn't it?

@laanwj
Copy link
Member Author

laanwj commented Oct 17, 2020

I think "Signing" here means "message sign/verify", doesn't it?

Yes, correct. I too think it's slightly misleading, because obviously without signing there would be no transactions. It refers to "message signing". But on the other hand it's consistent with the other uses of 'signing' in the UI, because signing of transactions happens in the background.

@maflcko
Copy link
Member

maflcko commented Oct 17, 2020

It would be good to leave a note for the translators in transifex

@andronoob
Copy link

With PSBT a user knows he "signs" transactions. Maybe he will doubt whether non-legacy addresses can be used for purposes like offline-signing (cold storage).

@laanwj
Copy link
Member Author

laanwj commented Oct 18, 2020 via email

@dongcarl
Copy link
Contributor

dongcarl commented Nov 4, 2020

Since I don't think we've split off yet, perhaps we should bump the deadline?

@maflcko
Copy link
Member

maflcko commented Nov 4, 2020

It is hard to predict the day of the split-off. Split-off can happen as soon as the majority of the bugfixes in the milestone has been merged or removed from the milestone: https://github.com/bitcoin/bitcoin/milestone/45

Splitting off before the milestone is empty doesn't help because rc1 can't be tagged either.

@laanwj
Copy link
Member Author

laanwj commented Nov 6, 2020

It always slips a bit. I suppose it shouldn't be called a deadline but more of a target. Anyhow all help is welcome in reviewing the remaining bugfix PRs!

@bitcoin bitcoin deleted a comment from gloriashaw Nov 27, 2020
@maflcko
Copy link
Member

maflcko commented Nov 27, 2020

rc2 is now available:

@maflcko maflcko mentioned this issue Dec 3, 2020
Closed
@estebansanchez32

This comment has been minimized.

Sign in to view
@laanwj
Copy link
Member Author

laanwj commented Jan 4, 2021

The rc cycle is taking longer than expected. I've moved the projected release date forward with two months, from 2020-12-03 to 2021-02-03.

@laanwj laanwj mentioned this issue Jan 4, 2021
Closed
@laanwj
Copy link
Member Author

laanwj commented Jan 13, 2021

v0.21.0 (final) was just tagged

@laanwj laanwj closed this as completed Jan 15, 2021
@fanquake fanquake unpinned this issue Jan 16, 2021
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.21.0
Development

No branches or pull requests
12 participants
@laanwj @dongcarl @andronoob @maflcko @estebansanchez32 and others