From f87e8f53920adfa80a3f4af9435370dc272c3783 Mon Sep 17 00:00:00 2001 From: "Wladimir J. van der Laan" Date: Fri, 17 Feb 2017 17:26:01 +0100 Subject: [PATCH] build: bump version to 0.14.99 Now that 0.14 branch has been split off, master is 0.14.99 (pre-0.15). Also clean out release notes. --- configure.ac | 2 +- doc/Doxyfile | 2 +- doc/README.md | 2 +- doc/README_windows.txt | 2 +- doc/release-notes.md | 111 ----------------------------------------- src/clientversion.h | 2 +- 6 files changed, 5 insertions(+), 116 deletions(-) diff --git a/configure.ac b/configure.ac index 346695043..64a623444 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N) AC_PREREQ([2.60]) define(_CLIENT_VERSION_MAJOR, 0) -define(_CLIENT_VERSION_MINOR, 13) +define(_CLIENT_VERSION_MINOR, 14) define(_CLIENT_VERSION_REVISION, 99) define(_CLIENT_VERSION_BUILD, 0) define(_CLIENT_VERSION_IS_RELEASE, false) diff --git a/doc/Doxyfile b/doc/Doxyfile index ef55acdbc..45436a6b1 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -38,7 +38,7 @@ PROJECT_NAME = "Bitcoin Core" # could be handy for archiving the generated documentation or if some version # control system is used. -PROJECT_NUMBER = 0.13.99 +PROJECT_NUMBER = 0.14.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a diff --git a/doc/README.md b/doc/README.md index 36684e540..09f32bc09 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin Core 0.13.99 +Bitcoin Core 0.14.99 ===================== Setup diff --git a/doc/README_windows.txt b/doc/README_windows.txt index 74a05138a..0e4c9ce04 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin Core 0.13.99 +Bitcoin Core 0.14.99 ===================== Intro diff --git a/doc/release-notes.md b/doc/release-notes.md index 0ea9e1949..eaa0b330e 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -33,117 +33,6 @@ frequently tested on them. Notable changes =============== -Low-level RPC changes ----------------------- - -- `importprunedfunds` only accepts two required arguments. Some versions accept - an optional third arg, which was always ignored. Make sure to never pass more - than two arguments. - -Fee Estimation Changes ----------------------- - -- Since 0.13.2 fee estimation for a confirmation target of 1 block has been - disabled. This is only a minor behavior change as there was often insufficient - data for this target anyway. `estimatefee 1` will now always return -1 and - `estimatesmartfee 1` will start searching at a target of 2. - -- The default target for fee estimation is changed to 6 blocks in both the GUI - (previously 25) and for RPC calls (previously 2). - -Removal of Priority Estimation -------------------------------- - -- Estimation of "priority" needed for a transaction to be included within a target - number of blocks has been removed. The rpc calls are deprecated and will either - return -1 or 1e24 appropriately. The format for `fee_estimates.dat` has also - changed to no longer save these priority estimates. It will automatically be - converted to the new format which is not readable by prior versions of the - software. - -- The concept of "priority" (coin age) transactions is planned to be removed in - the next major version. To prepare for this, the default for the rate limit of - priority transactions (`-limitfreerelay`) has been set to `0` kB/minute. This - is not to be confused with the `prioritisetransaction` RPC which will remain - supported for adding fee deltas to transactions. - -P2P connection management --------------------------- - -- Peers manually added through the addnode option or addnode RPC now have their own - limit of eight connections which does not compete with other inbound or outbound - connection usage and is not subject to the maxconnections limitation. - -- New connections to manually added peers are much faster. - -Introduction of assumed-valid blocks -------------------------------------- - -- A significant portion of the initial block download time is spent verifying - scripts/signatures. Although the verification must pass to ensure the security - of the system, no other result from this verification is needed: If the node - knew the history of a given block were valid it could skip checking scripts - for its ancestors. - -- A new configuration option 'assumevalid' is provided to express this knowledge - to the software. Unlike the 'checkpoints' in the past this setting does not - force the use of a particular chain: chains that are consistent with it are - processed quicker, but other chains are still accepted if they'd otherwise - be chosen as best. Also unlike 'checkpoints' the user can configure which - block history is assumed true, this means that even outdated software can - sync more quickly if the setting is updated by the user. - -- Because the validity of a chain history is a simple objective fact it is much - easier to review this setting. As a result the software ships with a default - value adjusted to match the current chain shortly before release. The use - of this default value can be disabled by setting -assumevalid=0 - -0.14.0 Change log -================= - -Detailed release notes follow. This overview includes changes that affect -behavior, not code moves, refactors and string updates. For convenience in locating -the code changes and accompanying discussion, both the pull request and -git merge commit are mentioned. - -### RPC and REST - -UTXO set query (`GET /rest/getutxos//-/-/.../-.`) responses -were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests -contain invalid parameters. - -The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change. - -Call "getmininginfo" loses the "testnet" field in favor of the more generic "chain" (which has been present for years). - -### Configuration and command-line options - -### Block and transaction handling - -### P2P protocol and network code - -### Validation - -### Build system - -### Wallet - -0.14.0 Fundrawtransaction change address reuse -============================================== - -Before 0.14, `fundrawtransaction` was by default wallet stateless. In almost all cases `fundrawtransaction` does add a change-output to the outputs of the funded transaction. Before 0.14, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse). -Before 0.14, calling `getnewaddress` directly after `fundrawtransaction` did generate the same address as the change-output address. - -Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting `reserveChangeKey`, default = `true`) - -Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option. - -### GUI - -### Tests - -### Miscellaneous - Credits ======= diff --git a/src/clientversion.h b/src/clientversion.h index 0b27bb1bd..69154d546 100644 --- a/src/clientversion.h +++ b/src/clientversion.h @@ -15,7 +15,7 @@ //! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it #define CLIENT_VERSION_MAJOR 0 -#define CLIENT_VERSION_MINOR 13 +#define CLIENT_VERSION_MINOR 14 #define CLIENT_VERSION_REVISION 99 #define CLIENT_VERSION_BUILD 0