diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/developer-notes.md | 11 | ||||
-rw-r--r-- | doc/release-notes.md | 7 | ||||
-rw-r--r-- | doc/release-process.md | 14 |
3 files changed, 24 insertions, 8 deletions
diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 49f60c54ec..b50f552e92 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -820,7 +820,7 @@ Current subtrees include: - **Note**: Follow the instructions in [Upgrading LevelDB](#upgrading-leveldb) when merging upstream changes to the LevelDB subtree. -- src/libsecp256k1 +- src/secp256k1 - Upstream at https://github.com/bitcoin-core/secp256k1/ ; actively maintained by Core contributors. - src/crypto/ctaes @@ -1014,7 +1014,7 @@ A few guidelines for introducing and reviewing new RPC interfaces: - A RPC method must either be a wallet method or a non-wallet method. Do not introduce new methods that differ in behavior based on the presence of a wallet. - - *Rationale*: as well as complicating the implementation and interfering + - *Rationale*: As well as complicating the implementation and interfering with the introduction of multi-wallet, wallet and non-wallet code should be separated to avoid introducing circular dependencies between code units. @@ -1041,8 +1041,13 @@ A few guidelines for introducing and reviewing new RPC interfaces: - *Rationale*: RPC methods registered with the same function pointer will be considered aliases and only the first method name will show up in the - `help` rpc command list. + `help` RPC command list. - *Exception*: Using RPC method aliases may be appropriate in cases where a new RPC is replacing a deprecated RPC, to avoid both RPCs confusingly showing up in the command list. + +- Use the `UNIX_EPOCH_TIME` constant when describing UNIX epoch time or + timestamps in the documentation. + + - *Rationale*: User-facing consistency. diff --git a/doc/release-notes.md b/doc/release-notes.md index 07caf0e53a..eec1ef9c46 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -78,6 +78,9 @@ New RPCs New settings ------------ +- RPC Whitelist system. It can give certain RPC users permissions to only some RPC calls. +It can be set with two command line arguments (`rpcwhitelist` and `rpcwhitelistdefault`). (#12763) + Updated settings ---------------- @@ -104,6 +107,10 @@ Low-level changes Tests ----- +- It is now an error to use an unqualified `walletdir=path` setting in the config file if running on testnet or regtest + networks. The setting now needs to be qualified as `chain.walletdir=path` or placed in the appropriate `[chain]` + section. (#17447) + - `-fallbackfee` was 0 (disabled) by default for the main chain, but 0.0002 by default for the test chains. Now it is 0 by default for all chains. Testnet and regtest users will have to add `fallbackfee=0.0002` to their configuration if they weren't setting it and they want it to keep working like before. (#16524) diff --git a/doc/release-process.md b/doc/release-process.md index 36d79a0c34..1ffef3e106 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -44,7 +44,8 @@ Release Process #### After branch-off (on the major release branch) -- Update the versions and the link to the release notes draft in `doc/release-notes.md`. +- Update the versions. +- Create a pinned meta-issue for testing the release candidate (see [this issue](https://github.com/bitcoin/bitcoin/issues/17079) for an example) and provide a link to it in the release announcements where useful. #### Before final release @@ -315,7 +316,7 @@ bitcoin.org (see below for bitcoin.org update instructions). instructions: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/adding-events-release-notes-and-alerts.md#release-notes - After the pull request is merged, the website will automatically show the newest version within 15 minutes, as well - as update the OS download links. Ping @saivann/@harding (saivann/harding on Freenode) in case anything goes wrong + as update the OS download links. - Update other repositories and websites for new version @@ -330,7 +331,12 @@ bitcoin.org (see below for bitcoin.org update instructions). - Notify BlueMatt so that he can start building [the PPAs](https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin) - - Create a new branch for the major release "0.xx" (used to build the snap package) + - Push the flatpak to flathub, e.g. https://github.com/flathub/org.bitcoincore.bitcoin-qt/pull/2 + + - Push the latest version to master (if applicable), e.g. https://github.com/bitcoin-core/packaging/pull/32 + + - Create a new branch for the major release "0.xx" from master (used to build the snap package) and request the + track (if applicable), e.g. https://forum.snapcraft.io/t/track-request-for-bitcoin-core-snap/10112/7 - Notify MarcoFalke so that he can start building the snap package @@ -354,8 +360,6 @@ bitcoin.org (see below for bitcoin.org update instructions). - Create a [new GitHub release](https://github.com/bitcoin/bitcoin/releases/new) with a link to the archived release notes - - Create a pinned meta-issue for testing the release candidate (see [this issue](https://github.com/bitcoin/bitcoin/issues/15555) for an example) and provide a link to it in the release announcements where useful - - Announce the release: - bitcoin-dev and bitcoin-core-dev mailing list |