Prepare for next release v2.4.0

Prepare Makefile and release notes for next release v2.4.0.

Signed-off-by: David Enyeart <enyeart@us.ibm.com>

Makefile

@@ -48,7 +48,7 @@
 #   - verify - runs unit tests for only the changed package tree
 
 ALPINE_VER ?= 3.13
-BASE_VERSION = 2.4.0-beta
+BASE_VERSION = 2.4.0
 
 # 3rd party image version
 # These versions are also set in the runners in ./integration/runners/

release_notes/v2.4.0.md

@@ -1,12 +1,12 @@
 v2.4.0 Release Notes - <Date TBD>
-===========================================
-
-These release notes extend the notes that have already been provided in the [v2.4.0-alpha release notes](https://github.com/hyperledger/fabric/releases/tag/v2.4.0-alpha)
+=================================
 
 New features
 ------------
 
-**FABGW-1: Fabric Gateway Technical Preview**
+**[FABGW-1] Fabric Gateway**
+
+Hyperledger Fabric v2.4.0 contains the new Fabric Gateway feature.
 
 The Fabric Gateway is a new component that will implement much of the high-level 'gateway' programming model in the Fabric peer,
 enabling the removal of much of the transaction submission and query logic from client applications, and shifting it to a common gateway component running within the Fabric peer.
@@ -16,27 +16,78 @@ The Fabric Gateway will also simplify the administrative overhead of running a F
 will be able to connect and submit transactions via a single network port rather than the current situation where ports
 have to be opened from a client application to multiple peers across potentially multiple organizations.
 
-The Fabric Gateway is delivered along with slim SDKs in the [https://github.com/hyperledger/fabric-gateway](https://github.com/hyperledger/fabric-gateway) repository,
-along with [client application samples](https://github.com/hyperledger/fabric-gateway/tree/main/samples).
+The Fabric Gateway is delivered along with slim SDKs in the [https://github.com/hyperledger/fabric-gateway](https://github.com/hyperledger/fabric-gateway) repository.
+Check out the [client application samples](https://github.com/hyperledger/fabric-gateway/tree/main/samples).
 
+**[FAB-11334] Unjoin a channel from a peer**
+
+The new command `peer node unjoin` enables an administrator to remove (unjoin) a channel from a peer.
+The peer must be stopped when the command is executed so that channel artifacts can be cleaned up.
+The channel's blockchain, state database, and associated entries will be removed from the peer.
+When the peer is restarted it will no longer receive blocks for the channel.
 
 Improvements
 ------------
 
-TBD
+**peer and orderer - Implement legacy name constraints verification for Go 1.15**
+
+These changes reproduce the Go 1.14 name constraint verification in the MSP.
+Without these changes, certificate chains that would fail verification in Go 1.14 would
+successfully validate in Go 1.15 due to the change mentioned in the [Go 1.15 release notes](https://golang.org/doc/go1.15#commonname).
+Specifically, if a signing certificate contains a name constraint, the leaf certificate
+does not include SAN extensions, and the leaf's common name looks like a host name,
+then the additional verification is performed to ensure deterministic behavior relative
+to prior Fabric releases.
+
+**peer and orderer - Default log record format improvements**
+
+Expanded the width of the log record sequence number to a minimum of four characters,
+moved the log sequence number and log level to the left,
+and added bold formatting to the function name.
+These changes keep the fixed-width columns together at the left
+and add a visual break between the logging module name and log message text.
+
+**peer - New configuration option to disable gossip block forwarding**
+
+If all peers in an organization explicitly set "peer.deliveryclient.blockGossipEnabled" to false,
+no peer in the organization gossips blocks to any other peer in that organization.
+Use this setting when all peers pull blocks from ordering service. For more
+information see deprecation announcement below: **FAB-15317: Block dissemination via gossip is deprecated**.
+
+**orderer - [FAB-18484] Return transaction forwarding result back to the client synchronously**
+
+With this improvement a Raft follower waits for the transaction to be forwarded to the Raft leader,
+and returns the result (success or failure) back to the client accordingly.
+Prior to this improvement, the Raft follower returned success after enqueueing it into the message queue,
+which might have resulted in the transaction being dropped but a success being returned to the client.
+Application clients should still monitor transaction commit events, since the Raft leader is not guaranteed
+to deliver the transaction into a block in exception scenarios, but this improvement avoids
+transactions from being dropped when there are connection issues between a Raft follower and Raft leader.
+
+**peer - Ability to override core.yaml chaincode.externalBuilders via environment variable**
+
+Since chaincode.externalBuilders is an array, it previously was not possible to set via environment variable override.
+It is now possible to override chaincode.externalBuilders using an environment variable
+using the format `CORE_CHAINCODE_EXTERNALBUILDERS=[{name: x, path: dir1}, {name: y, path: dir2}]`.
 
 
 Fixes
 -----
 All fixes as of v2.3.2 are included in v2.4.0. Additionally, the following fixes are made in v2.4.0.
 
-TBD
+**orderer - [FAB-18521] Consenters' metadata is not replicated while OSN catches up with snapshot**
+
+If an ordering service node crashes while replicating blocks from another ordering service,
+the consenters metadata will not be available and the ordering service node will not be
+able to reconnect to the consenter set upon restart. This fix ensures that an ordering
+service node that is replicating blocks persists the consenters metadata so that it
+can reconnect to the consenter set.
 
 
 Dependencies
 ------------
 Fabric v2.4.0 has been tested with the following dependencies:
-* Go 1.15.7
+* Go 1.16.7
 * CouchDB v3.1.1
 * Alpine images 3.13
 
@@ -97,11 +148,12 @@ to Fabric runtime components, regardless of where the Fabric components are runn
 
 Block dissemination via gossip is deprecated and may be removed in a future release.
 Fabric peers can be configured to receive blocks directly from an ordering service
-node by using the following configuration:
+node and not gossip blocks by using the following configuration:
 ```
 peer.gossip.orgLeader: true
 peer.gossip.useLeaderElection: false
 peer.gossip.state.enabled: false
+peer.deliveryclient.blockGossipEnabled: false
 ```
 
 **FAB-15061: Legacy chaincode lifecycle is deprecated**