Prepare v0.30.0 (#3287)

* changelog, upgrading, version

* update for evidence fixes

* linkify

* fix an entry

CHANGELOG.md

@@ -1,5 +1,52 @@
 # Changelog
 
+## v0.30.0
+
+*February 8th, 2019*
+
+This release fixes yet another issue with the proposer selection algorithm.
+We hope it's the last one, but we won't be surprised if it's not.
+We plan to one day expose the selection algorithm more directly to
+the application ([\#3285](https://github.com/tendermint/tendermint/issues/3285)), and even to support randomness ([\#763](https://github.com/tendermint/tendermint/issues/763)).
+For more, see issues marked
+[proposer-selection](https://github.com/tendermint/tendermint/labels/proposer-selection).
+
+This release also includes a fix to prevent Tendermint from including the same
+piece of evidence in more than one block. This issue was reported by @chengwenxi in our
+[bug bounty program](https://hackerone.com/tendermint).
+
+### BREAKING CHANGES:
+
+* Apps
+  - [state] [\#3222](https://github.com/tendermint/tendermint/issues/3222)
+    Duplicate updates for the same validator are forbidden. Apps must ensure
+    that a given `ResponseEndBlock.ValidatorUpdates` contains only one entry per pubkey.
+
+* Go API
+  - [types] [\#3222](https://github.com/tendermint/tendermint/issues/3222)
+    Remove `Add` and `Update` methods from `ValidatorSet` in favor of new
+    `UpdateWithChangeSet`. This allows updates to be applied as a set, instead of
+    one at a time.
+
+* Block Protocol
+  - [state] [\#3286](https://github.com/tendermint/tendermint/issues/3286) Blocks that include already committed evidence are invalid.
+
+* P2P Protocol
+  - [consensus] [\#3222](https://github.com/tendermint/tendermint/issues/3222)
+    Validator updates are applied as a set, instead of one at a time, thus
+    impacting the proposer priority calculation. This ensures that the proposer
+    selection algorithm does not depend on the order of updates in
+    `ResponseEndBlock.ValidatorUpdates`.
+
+### IMPROVEMENTS:
+- [crypto] [\#3279](https://github.com/tendermint/tendermint/issues/3279) Use `btcec.S256().N` directly instead of hard coding a copy.
+
+### BUG FIXES:
+- [state] [\#3222](https://github.com/tendermint/tendermint/issues/3222) Fix validator set updates so they are applied as a set, rather
+  than one at a time. This makes the proposer selection algorithm independent of
+  the order of updates in `ResponseEndBlock.ValidatorUpdates`.
+- [evidence] [\#3286](https://github.com/tendermint/tendermint/issues/3286) Don't add committed evidence to evidence pool.
+
 ## v0.29.2
 
 *February 7th, 2019*
@@ -11,7 +58,7 @@ Special thanks to external contributors on this release:
 `crypto` packages:
 - p2p:
   - Partial fix for MITM attacks on the p2p connection. MITM conditions may
-    still exist. See \#3010.
+    still exist. See [\#3010](https://github.com/tendermint/tendermint/issues/3010).
 - crypto:
   - Eliminate our fork of `btcd` and use the `btcd/btcec` library directly for
     native secp256k1 signing. Note we still modify the signature encoding to

CHANGELOG_PENDING.md

@@ -1,4 +1,4 @@
-## v0.30
+## v0.31.0
 
 **
 
@@ -14,8 +14,6 @@ Special thanks to external contributors on this release:
 
 * Blockchain Protocol
 
- - [types] Reject blocks which contain already committed evidence
-
 * P2P Protocol
 
 ### FEATURES:
@@ -23,6 +21,3 @@ Special thanks to external contributors on this release:
 ### IMPROVEMENTS:
 
 ### BUG FIXES:
-
- - [evidence] Do not store evidence which was already marked as committed
-

UPGRADING.md

@@ -3,6 +3,29 @@
 This guide provides steps to be followed when you upgrade your applications to
 a newer version of Tendermint Core.
 
+## v0.30.0
+
+This release contains a breaking change to both the block and p2p protocols,
+however it may be compatible with blockchains created with v0.29.0 depending on
+the chain history. If your blockchain has not included any pieces of evidence,
+or no piece of evidence has been included in more than one block,
+and if your application has never returned multiple updates
+for the same validator in a single block, then v0.30.0 will work fine with
+blockchains created with v0.29.0.
+
+The p2p protocol change is to fix the proposer selection algorithm again.
+Note that proposer selection is purely a p2p concern right
+now since the algorithm is only relevant during real time consensus.
+This change is thus compatible with v0.29.0, but
+all nodes must be upgraded to avoid disagreements on the proposer.
+
+### Applications
+
+Applications must ensure they do not return duplicates in
+`ResponseEndBlock.ValidatorUpdates`. A pubkey must only appear once per set of
+updates. Duplicates will cause irrecoverable failure. If you have a very good
+reason why we shouldn't do this, please open an issue.
+
 ## v0.29.0
 
 This release contains some breaking changes to the block and p2p protocols,

version/version.go

@@ -20,7 +20,7 @@ const (
 	// Must be a string because scripts like dist.sh read this file.
 	// XXX: Don't change the name of this variable or you will break
 	// automation :)
-	TMCoreSemVer = "0.29.2"
+	TMCoreSemVer = "0.30.0"
 
 	// ABCISemVer is the semantic version of the ABCI library
 	ABCISemVer  = "0.15.0"
@@ -38,10 +38,12 @@ func (p Protocol) Uint64() uint64 {
 
 var (
 	// P2PProtocol versions all p2p behaviour and msgs.
-	P2PProtocol Protocol = 6
+	// This includes proposer selection.
+	P2PProtocol Protocol = 7
 
 	// BlockProtocol versions all block data structures and processing.
-	BlockProtocol Protocol = 9
+	// This includes validity of blocks and state updates.
+	BlockProtocol Protocol = 10
 )
 
 //------------------------------------------------------------------------