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.

6 files changed, 5 insertions, 116 deletions

diff --git a/configure.ac b/configure.ac
index 346695043d..64a6234449 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 ef55acdbc3..45436a6b15 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 36684e5401..09f32bc09e 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 74a05138a4..0e4c9ce04f 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 0ea9e1949e..eaa0b330eb 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/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`) 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 0b27bb1bdf..69154d546d 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