|
| 1 | +v2.5.12 Release Notes - March 10, 2025 |
| 2 | +====================================== |
| 3 | + |
| 4 | +Fixes |
| 5 | +----- |
| 6 | + |
| 7 | +**Fix peer panic from gossip/gossip/algo** |
| 8 | + |
| 9 | +Occasionally a peer may panic due to outdated math/rand dependency with message |
| 10 | +`panic: runtime error: index out of range [-1]`. |
| 11 | +[5170](https://github.com/hyperledger/fabric/pull/5170) |
| 12 | + |
| 13 | +**Fix peer panic from fabric/gossip/util** |
| 14 | + |
| 15 | +On an active network with many channels and many peers, a peer may panic with the message |
| 16 | +`panic: runtime error: invalid memory address or nil pointer dereference`. |
| 17 | +[#5138](https://github.com/hyperledger/fabric/pull/5138) |
| 18 | + |
| 19 | +Dependencies |
| 20 | +------------ |
| 21 | +Fabric v2.5.12 has been tested with the following dependencies: |
| 22 | +* Go 1.23.5 |
| 23 | +* CouchDB v3.4.2 |
| 24 | + |
| 25 | +Go dependencies have also been updated. |
| 26 | + |
| 27 | +Fabric docker images on dockerhub utilize Ubuntu 22.04. |
| 28 | + |
| 29 | + |
| 30 | +Deprecations (existing) |
| 31 | +----------------------- |
| 32 | + |
| 33 | +**Ordering service system channel is deprecated** |
| 34 | + |
| 35 | +v2.3 introduced the ability to manage an ordering service without a system channel. |
| 36 | +Managing an ordering service without a system channel has privacy, scalability, |
| 37 | +and operational benefits. The use of a system channel is deprecated and may be removed in a future release. |
| 38 | +For information about removal of the system channel, see the [Create a channel without system channel documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.3/create_channel/create_channel_participation.html). |
| 39 | + |
| 40 | +**FAB-15754: The 'Solo' consensus type is deprecated.** |
| 41 | + |
| 42 | +The 'Solo' consensus type has always been marked non-production and should be in |
| 43 | +use only in test environments; however, for compatibility it is still available, |
| 44 | +but may be removed entirely in a future release. |
| 45 | + |
| 46 | +**FAB-16408: The 'Kafka' consensus type is deprecated.** |
| 47 | + |
| 48 | +The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred |
| 49 | +production consensus type. There is a documented and tested migration path from |
| 50 | +Kafka to Raft, and existing users should migrate to the newer Raft consensus type. |
| 51 | +For compatibility with existing deployments, Kafka is still supported, |
| 52 | +but may be removed entirely in a future release. |
| 53 | +Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published. |
| 54 | + |
| 55 | +**Fabric CouchDB image is deprecated** |
| 56 | + |
| 57 | +v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB. |
| 58 | +If prior versions are utilized, a Warning will appear in the peer log. |
| 59 | +Note that CouchDB 3.1.0 requires that an admin username and password be set, |
| 60 | +while this was optional in CouchDB v2.x. See the |
| 61 | +[Fabric CouchDB documentation](https://hyperledger-fabric.readthedocs.io/en/v2.2.0/couchdb_as_state_database.html#couchdb-configuration) |
| 62 | +for configuration details. |
| 63 | +Also note that CouchDB 3.1.0 default max_document_size is reduced to 8MB. Set a higher value if needed in your environment. |
| 64 | +Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published. |
| 65 | +Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead. |
| 66 | + |
| 67 | +**FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.** |
| 68 | + |
| 69 | +Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead. |
| 70 | +Configuring orderer endpoints at the organization level accommodates |
| 71 | +scenarios where orderers are run by different organizations. Using |
| 72 | +this configuration ensures that only the TLS CA certificates of that organization |
| 73 | +are used for orderer communications; in contrast to the global channel level endpoints which |
| 74 | +would cause an aggregation of all orderer TLS CA certificates across |
| 75 | +all orderer organizations to be used for orderer communications. |
| 76 | + |
| 77 | +**FAB-17428: Support for configtxgen flag `--outputAnchorPeersUpdate` is deprecated.** |
| 78 | + |
| 79 | +The `--outputAnchorPeersUpdate` mechanism for updating anchor peers has always had |
| 80 | +limitations (for instance, it only works the first time anchor peers are updated). |
| 81 | +Instead, anchor peer updates should be performed through channel configuration updates. |
| 82 | + |
| 83 | +**FAB-15406: The fabric-tools docker image is deprecated** |
| 84 | + |
| 85 | +The fabric-tools docker image will not be published in future Fabric releases. |
| 86 | +Instead of using the fabric-tools docker image, users should utilize the |
| 87 | +published Fabric binaries. The Fabric binaries can be used to make client calls |
| 88 | +to Fabric runtime components, regardless of where the Fabric components are running. |
| 89 | + |
| 90 | +**FAB-15317: Block dissemination via gossip is deprecated** |
| 91 | + |
| 92 | +Block dissemination via gossip is deprecated and may be removed in a future release. |
| 93 | +Fabric peers can be configured to receive blocks directly from an ordering service |
| 94 | +node, and not gossip blocks, by using the following configuration: |
| 95 | +``` |
| 96 | +peer.gossip.orgLeader: true |
| 97 | +peer.gossip.useLeaderElection: false |
| 98 | +peer.gossip.state.enabled: false |
| 99 | +peer.deliveryclient.blockGossipEnabled: false |
| 100 | +``` |
| 101 | + |
| 102 | +**FAB-15061: Legacy chaincode lifecycle is deprecated** |
| 103 | + |
| 104 | +The legacy chaincode lifecycle from v1.x is deprecated and will be removed |
| 105 | +in a future release. To prepare for the eventual removal, utilize the v2.x |
| 106 | +chaincode lifecycle instead, by enabling V2_0 application capability on all |
| 107 | +channels, and redeploying all chaincodes using the v2.x lifecycle. The new |
| 108 | +chaincode lifecycle provides a more flexible and robust governance model |
| 109 | +for chaincodes. For more details see the |
| 110 | +[documentation for enabling the new lifecycle](https://hyperledger-fabric.readthedocs.io/en/release-2.2/enable_cc_lifecycle.html). |
0 commit comments