Doc: Update release notes for master through to 2019-01-01 #15081

harding commented at 8:51 PM on January 2, 2019: contributor

This adds release notes for the changes listed by git log 11e1ac3...fb52d0684 --merges, picking up where #14688 left off in my attempt to update the release notes every month or so (reducing the amount of work that needs to be done near release time). I've excluded changes backported to the 0.17 branch (whether they've been released yet or not).

fanquake added the label Docs on Jan 2, 2019

in doc/release-notes.md:291 in c059ca31a5 outdated

 284 | @@ -216,6 +285,16 @@ Configuration
 285 |    deterministic wallets. This release makes specifying `-usehd` an
 286 |    invalid configuration option.
 287 |  
 288 | +Changes for particular platforms
 289 | +--------------------------------
 290 | +
 291 | +- On MacOS, Bitcoin Core now opts out of application CPU throttling

fanquake commented at 12:10 AM on January 3, 2019:

MacOS -> macOS

in doc/release-notes.md:292 in c059ca31a5 outdated

 284 | @@ -216,6 +285,16 @@ Configuration
 285 |    deterministic wallets. This release makes specifying `-usehd` an
 286 |    invalid configuration option.
 287 |  
 288 | +Changes for particular platforms
 289 | +--------------------------------
 290 | +
 291 | +- On MacOS, Bitcoin Core now opts out of application CPU throttling
 292 | +  ("app nap") during initial block chain download, when catching up from

fanquake commented at 12:10 AM on January 3, 2019:

block chain -> blockchain

harding commented at 12:58 AM on January 3, 2019:

I'm happy to change this, but is this the repository's policy or just your preference? In previous (but admittedly dated) discussions I recall about this topic, the use of "block chain" (two words) was preferred. E.g., #1910, #5242, and #6666

fanquake commented at 1:01 AM on January 3, 2019:

@harding I'm not really fussed either way, was more for consistency with the rest of file. All other uses in here are blockchain.

harding commented at 1:25 AM on January 3, 2019:

Fair enough. Thanks!

in doc/release-notes.md:252 in c059ca31a5 outdated

 247 |  - See the [Mining](#mining) section for changes to `getblocktemplate`.
 248 |  
 249 | +Graphical User Interface (GUI)
 250 | +------------------------------
 251 | +
 252 | +- A new Window menu is added alongside the existing File, Settings, and

fanquake commented at 12:11 AM on January 3, 2019:

is -> has been

harding commented at 1:10 AM on January 3, 2019:

"is added" appears to be grammatically correct and is used 28 times in the current source code per git grep. But, if you insist, I'm happy to change it (I prefer it over alternatives for its brevity).

in doc/release-notes.md:232 in c059ca31a5 outdated

 227 | +  optional redeemScript, and optional witnessScript in order for the
 228 | +  wallet to be able to generate an unsigned input spending funds sent to
 229 | +  that address.
 230 | +
 231 | +- The `getaddressinfo`, `listunspent`, and `scantxoutset` RPCs now
 232 | +  returns an additional `desc` field that contains an output descriptor

fanquake commented at 12:13 AM on January 3, 2019:

returns -> return

in doc/release-notes.md:257 in c059ca31a5 outdated

 252 | +- A new Window menu is added alongside the existing File, Settings, and
 253 | +  Help menus.  Several items from the other menus that opened new
 254 | +  windows have been moved to this new Window menu.
 255 | +
 256 | +- In the GUI's Send tab, the checkbox for "pay only the required fee"
 257 | +  has been removed.  Instead, the user is prevented from entering a

fanquake commented at 12:18 AM on January 3, 2019:

Saying the user feels weird here. Maybe something like Instead, it is now impossible to enter a custom feerate below the minimum required?

Also, given that we're in the GUI section of the release notes here, I think we could drop In the GUI's from each paragraph, and just say In the Overview tab... & In the Send tab... etc.

in doc/release-notes.md:104 in c059ca31a5 outdated

 109 | +- The `rpcallowip` option can no longer be used to automatically listen
 110 | +  on all network interfaces.  Instead, the `rpcbind` parameter must also
 111 | +  be used to specify the IP addresses to listen on.  Listening for RPC
 112 | +  commands over a public network connection is insecure and should be
 113 | +  disabled, so a warning is now printed if a user selects such a
 114 | +  configuration.  If you need to expose RPC in order to use a tool

fanquake commented at 12:21 AM on January 3, 2019:

expose RPC -> expose the RPC

harding commented at 1:22 AM on January 3, 2019:

Why? We don't typically require the use of an article before the name of a protocol, e.g. "If you need to expose {HTTP, SMTP, IMAP, SSL, bittorrent, ...} in order to use..."

in doc/release-notes.md:105 in c059ca31a5 outdated

 110 | +  on all network interfaces.  Instead, the `rpcbind` parameter must also
 111 | +  be used to specify the IP addresses to listen on.  Listening for RPC
 112 | +  commands over a public network connection is insecure and should be
 113 | +  disabled, so a warning is now printed if a user selects such a
 114 | +  configuration.  If you need to expose RPC in order to use a tool
 115 | +  like Docker, ensure you bind RPC to only your localhost, e.g. `docker

fanquake commented at 12:22 AM on January 3, 2019:

ensure you only bind the RPC to your localhost

fanquake changes_requested

Release notes: update notes through fb52d0684 97fbe67940

Release notes: integrate detached release notes f3d7d75e4e

harding force-pushed on Jan 3, 2019

fanquake commented at 1:49 AM on January 3, 2019: member

Thanks, utACK f3d7d75. Not fussed about the other changes.

fanquake approved

fanquake commented at 8:58 AM on January 3, 2019: member

Thanks, utACK f3d7d75. Not fussed about the other changes.

laanwj commented at 9:00 AM on January 3, 2019: member

Thanks !!!

ACK f3d7d75e4e80bcd2c6058babb732c9c6cc7522c6

laanwj merged this on Jan 3, 2019

laanwj closed this on Jan 3, 2019

laanwj referenced this in commit 031e3a32b2 on Jan 3, 2019

MarcoFalke commented at 1:19 PM on January 5, 2019: member

I've excluded changes backported to the 0.17 branch (whether they've been released yet or not).

Are they mentioned in the release notes on that branch?

harding commented at 2:16 PM on January 5, 2019: contributor

@MarcoFalke I didn't check. However, I don't believe any of the detached release notes I integrated applied to anything that had been backported to 0.17 so far, so no information should've been lost. (I did not check pre-0.17 branches.)

The list of noteworthy changes for a typical maintenance release are much smaller than those for a major release, so I don't think the non-master branches would benefit much from periodic release notes updates (but, if you disagree, I'm happy to start opening PRs for that).

If there's anything I can do better, please let me know (or let me know if these updates are annoying and I'll stop).

MarcoFalke commented at 2:21 PM on January 5, 2019: member

Oh no, they are very helpful. Usually we had no release notes at all for the whole rc cycle.

What I meant to say is that sometimes release notes get added to the master branch, but not the backport.

E.g. https://github.com/bitcoin/bitcoin/pull/14941/files#diff-c3924c30088c7adb0477128540f35c11R1 and https://github.com/bitcoin/bitcoin/pull/15002/files

So, it would be a pity if the notes get lost due to an oversight.

harding commented at 2:48 PM on January 5, 2019: contributor

@MarcoFalke Ah. So far I haven't removed anything from the notes for master because of a backport. If I do remove anything, I'll be sure that it's documented at least on the current stable branch.

Somewhat related, I was wondering if it'd be useful to tag each item in the release note with the PR or PRs that went into it so that interested readers can learn more about the context. If I do that, it ought to at least make it easier to grep whether the release notes contain any text about a backport of PRxxxxx.

DrahtBot locked this on Dec 16, 2021