Skip to content

Commit 7cd1eda

Browse files
committed
Add release notes for v2.0.0-beta
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
1 parent 5deab9a commit 7cd1eda

File tree

1 file changed

+196
-0
lines changed

1 file changed

+196
-0
lines changed

release_notes/v2.0.0-beta.md

Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
v2.0.0-beta Release Notes - December 12, 2019
2+
=============================================
3+
4+
What's New in Hyperledger Fabric v2.0
5+
-------------------------------------
6+
7+
The following new major features are included in the v2.0.0 Beta release.
8+
For additional details, see the What's New documentation.
9+
10+
**FAB-11237: Decentralized chaincode governance**
11+
12+
Fabric 2.0 introduces decentralized governance for chaincode, with a
13+
new process for installing a chaincode on your peers and starting it on a
14+
channel. The new Fabric chaincode lifecycle allows multiple organizations to
15+
come to agreement on the parameters of a chaincode, such as the chaincode
16+
endorsement policy, before it can be used to interact with the ledger.
17+
18+
**FAB-13584: External chaincode launcher**
19+
20+
While chaincode is still run in a docker container by default in Fabric v2.0,
21+
the external chaincode launcher feature empowers operators to build and launch
22+
chaincode with the technology of their choice.
23+
24+
**Private data enhancements**
25+
- **FAB-10889: Implicit org-specific collections**
26+
- **FAB-15066: Endorsement policies for collections**
27+
- **FAB-13581: memberOnlyWrite collection configuration option**
28+
- **FAB-13527: GetPrivateDataHash chaincode API**
29+
- **FAB-12043: Option to include private data in block events**
30+
31+
The private data enhancements enable new private data application patterns.
32+
33+
**FAB-103: State database cache for CouchDB**
34+
35+
A new peer cache improves performance when using CouchDB state database.
36+
37+
38+
Fixes
39+
-----
40+
All fixes as of release v1.4.4 are also included in v2.0.0-beta.
41+
42+
For the full list of fixes, refer to the release change log.
43+
44+
45+
Changes
46+
-------
47+
**FAB-11144: Removal of native token support**
48+
49+
The native token support included in v2.0.0-alpha has been removed.
50+
An improved implementation is being evaluated for future releases.
51+
52+
**FAB-5177: The ccenv build image no longer includes the shim**
53+
54+
The shim package and dependencies for go chaincode are no longer included in
55+
the chaincode build environment. Chaincode packages that do not include their
56+
own dependencies will no longer successfully build on the peer. We strongly
57+
recommend that existing go chaincode be updated to vendor the
58+
github.com/hyperledger/fabric-chaincode-go/shim package and its dependencies.
59+
While there are many tools for managing vendored dependencies, we recommend
60+
moving directly to go modules and vendoring with `go mod vendor`.
61+
62+
**FAB-15366: Logger removed from chaincode shim**
63+
64+
Chaincode that used the shim's NewLogger() will need to shift to a new
65+
logging mechanism. Chaincode logging is intended to be the responsibility
66+
of the application developer. As such it should be handled using tools and
67+
libraries that make the most sense to the chaincode developer and the
68+
application in general. Chaincode developers can forward STDOUT and STDERR
69+
from the chaincode container to the peer container by setting
70+
`CORE_VM_DOCKER_ATTACHSTDOUT=true`. While not recommended for production,
71+
once enabled, each chaincode will receive its own logging channel and
72+
STDOUT and STDERR will be integrated in the peers log on a per-line basis.
73+
A production grade approach would be to run a log aggregation service and
74+
forward your logs to the aggregation service.
75+
76+
**FAB-16213: The go chaincode entities extension has been removed**
77+
78+
Chaincode implementations that used the entities extension package from an
79+
earlier version of Fabric will need to vendor a 1.x version of the package
80+
for as part of their chaincode package.
81+
82+
**FAB-14720: Support for CAR chaincode package format removed**
83+
84+
**FAB-15285: Support for invoking system chaincodes from user chaincodes
85+
has been removed.**
86+
87+
System chaincodes, for example QSCC, are intended to be
88+
invoked by a client rather than by a user chaincode. Invoking from a user
89+
chaincode caused deadlocks in prior releases.
90+
91+
**FAB-15390: Support for peer's Admin service has been removed.**
92+
93+
The peer's Admin service exposed APIs such as GetLogSpec() and SetLogSpec().
94+
Instead of using these services, utilize the HTTP operations service that was
95+
introduced in v1.4.0.
96+
97+
**FAB-16303: GetHistoryForKey returns results from newest to oldest**
98+
99+
In prior releases, the GetHistoryForKey chaincode API had no
100+
guarantees on the order of returned results.
101+
Starting in Fabric v2.0, the GetHistoryForKey chaincode API
102+
will return results from newest to oldest in terms of ordered transaction
103+
height (block height and transaction height within block).
104+
This will allow applications to iterate through the top results
105+
to understand recent changes to a key.
106+
107+
**FAB-16722: The 'provisional' genesis method of generating the system channel
108+
for orderers has been removed.**
109+
110+
Existing users of the provisional genesis method
111+
should instead set BootstrapMethod to 'file', and generate a genesis block file
112+
using configtxgen. Orderer nodes will then use the generated file for the
113+
orderer system channel.
114+
115+
**FAB-16477 and FAB-17116: New configuration for orderer genesismethod and genesisfile**
116+
117+
The orderer config `general.genesismethod` and `general.genesisfile` are replaced
118+
by the new `general.bootstrapmethod` and `general.bootstrapfile`.
119+
120+
**FAB-15343: System Chaincode Plugins have been removed.**
121+
122+
As part of a general
123+
move away from go plugins as an extension mechanism for Fabric, the ability to
124+
add system chaincodes via go plugins has been removed. Users wishing to extend
125+
Fabric with custom system chaincodes may rebuild the peer binary with the
126+
system chaincode built into the binary. This system chaincode should then be
127+
defined and initialized like any other user chaincode would be. This new model
128+
is very similar to the plugin model (which required that the plugin to be built
129+
at the same exact commit of Fabric), and addresses the significant shortcomings
130+
around the lifecycle and validation of system chaincode transactions.
131+
132+
**FAB-11096: Docker images with Alpine Linux**
133+
134+
Hyperledger Fabric Docker images will now use Alpine Linux,
135+
a security-oriented, lightweight Linux distribution.
136+
137+
**FAB-11096: Bash not available in Docker images with Alpine Linux**
138+
Bash is no longer available in Fabric images. Utilize Alpine's built-in
139+
sh or ash instead.
140+
141+
**FAB-16987: Go version has been updated to 1.13.4.**
142+
143+
144+
Deprecations
145+
------------
146+
147+
**FAB-15754: The 'Solo' consensus type is deprecated.**
148+
149+
The 'Solo' consensus type has always been marked non-production and should be in
150+
use only in test environments, however for compatibility it is still available,
151+
but may be removed entirely in a future release.
152+
153+
**FAB-16408: The 'Kafka' consensus type is deprecated.**
154+
155+
The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred
156+
production consensus type. There is a documented and tested migration path from
157+
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.
158+
For compatibility with existing deployments, Kafka is still supported,
159+
but may be removed entirely in a future release.
160+
161+
**FAB-7559: Support for specifying orderer endpoints at the global level
162+
in channel configuration is deprecated.**
163+
164+
Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.
165+
Configuring orderer endpoints at the organization level accommodates
166+
scenarios where orderers are run by different organizations. Using
167+
this configuration ensures that only the TLS CA certificates of that organization
168+
are used for orderer communications, in contrast to the global channel level endpoints which
169+
would cause an aggregation of all orderer TLS CA certificates across
170+
all orderer organizations to be used for orderer communications.
171+
172+
Known Issues and Workarounds
173+
----------------------------
174+
**FAB-12134: Same chaincode source receiving fingerprint mismatch error**
175+
176+
When using the legacy chaincode lifecycle, chaincode installed in different
177+
ways may result in "chaincode fingerprint mismatch data mismatch" error
178+
upon instantiation. This may happen when installing chaincode by using
179+
different SDKs. To workaround the problem, package the chaincode prior to
180+
installation and instantiation, by using the "peer chaincode package" command.
181+
182+
183+
Known Vulnerabilities
184+
---------------------
185+
**FAB-8664: Peer should detect and react when its org has been removed**
186+
187+
This is a relatively low severity problem, because it requires a significant
188+
conspiracy of network admins, but it will be addressed in a future release.
189+
190+
191+
Resolved Vulnerabilities
192+
------------------------
193+
None.
194+
195+
For the full list of improvements and fixes, refer to the release change log:
196+
https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v200-beta

0 commit comments

Comments
 (0)