[FAB-13113] Release fabric v1.4.0-rc1

Change-Id: I66fc1f9ef8f9820cb8b990f3cf18d845a5a66343
Signed-off-by: David Enyeart <[email protected]>

Makefile

@@ -44,7 +44,7 @@
 #   - docker-tag-stable - re-tags the images made by 'make docker' with the :stable tag
 #   - help-docs - generate the command reference docs
 
-BASE_VERSION = 1.4.0
+BASE_VERSION = 1.4.0-rc1
 PREV_VERSION = 1.3.0
 CHAINTOOL_RELEASE=1.1.3
 BASEIMAGE_RELEASE=0.4.14

README.md

@@ -28,6 +28,7 @@ open source architecture; Hyperledger Fabric is your starting point.
 
 ## Releases
 
+- [v1.4.0-rc1 - December 10, 2018](https://github.com/hyperledger/fabric/releases/tag/v1.4.0-rc1)
 - [v1.3.0 - October 10, 2018](https://github.com/hyperledger/fabric/releases/tag/v1.3.0)
 - [v1.3.0-rc1 - September 24, 2018](https://github.com/hyperledger/fabric/releases/tag/v1.3.0-rc1)
 - [v1.2.0 - July 3, 2018](https://github.com/hyperledger/fabric/releases/tag/v1.2.0)
@@ -58,6 +59,7 @@ Please visit the [Hyperledger Fabric wiki](https://wiki.hyperledger.org/projects
 Please visit our
 online documentation for
 information on getting started using and developing with the fabric, SDK and chaincode:
+- [v1.4](http://hyperledger-fabric.readthedocs.io/en/release-1.4/)
 - [v1.3](http://hyperledger-fabric.readthedocs.io/en/release-1.3/)
 - [v1.2](http://hyperledger-fabric.readthedocs.io/en/release-1.2/)
 - [v1.1](http://hyperledger-fabric.readthedocs.io/en/release-1.1/)

docs/source/install.rst

@@ -41,15 +41,15 @@ Fabric Samples and binaries, go ahead and execute the following command:
 
 .. code:: bash
 
-  curl -sSL http://bit.ly/2ysbOFE | bash -s 1.3.0
+  curl -sSL http://bit.ly/2ysbOFE | bash -s 1.4.0-rc1
 
 .. note:: If you want to download different versions for Fabric, Fabric-ca and thirdparty
           Docker images, you must pass the version identifier for each.
 
 .. code:: bash
 
   curl -sSL http://bit.ly/2ysbOFE | bash -s <fabric> <fabric-ca> <thirdparty>
-  curl -sSL http://bit.ly/2ysbOFE | bash -s 1.3.0 1.3.0 0.4.13
+  curl -sSL http://bit.ly/2ysbOFE | bash -s 1.4.0-rc1 1.4.0-rc1 0.4.14
 
 .. note:: If you get an error running the above curl command, you may
           have too old a version of curl that does not handle
@@ -62,7 +62,7 @@ Fabric Samples and binaries, go ahead and execute the following command:
 	  https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh
 
 .. note:: You can use the command above for any published version of Hyperledger
-          Fabric. Simply replace `1.3.0` with the version identifier
+          Fabric. Simply replace `1.4.0-rc1` with the version identifier
           of the version you wish to install.
 
 The command above downloads and executes a bash script

release_notes/v1.4.0.txt

@@ -1,85 +1,125 @@
+v1.4.0-rc1 Release Notes - December 10, 2018
+--------------------------------------------
 
-What's New in v1.4
-------------------
+What's New in Hyperledger Fabric v1.4
+-------------------------------------
 
-FAB-12357 - Updates to logging
-
-In earlier versions of Fabric, loggers were associated with named components
-and configuration would control the active level of each logger. While this
-model works in theory, because of the configuration management libraries used
-by Fabric and the structure of the Fabric code base, in practice it had a
-number of issues.
-
-With 1.4, we're changing the model slightly. Instead of associating loggers
-with components, we are naming loggers and to help avoid side effects during
-initialization, the logging configuration is no longer obtained from the
-fabric configuration system but from environment variables that define
-the logging specification and log format.
-
-The log specification is a single string that consists of colon separated
-tokens. Each token declares one or more logger name prefixes (separated by
-commas) and an optional log level. When the logger name prefix ends with a
-period, it indicates that the log level should only apply to the logger with
-that exact name without the trailing period. When the logger name pattern is
-omitted, it specifies the default log level. In cases where multiple entries
-reference the same name pattern or multiple instances of a default are
-provided, the last specification takes precedence.
-
-The Fabric Operations Server
+The following features are included in this release:
 
+Fabric operations service
 A new HTTP based "operations" endpoint has been implemented on the orderer and
 the peer. The endpoint exposes APIs to check the server's health, to query
 and modify the logging level of the process, and, when configured, to expose
 Fabric metrics.
 
-FAB-12358 - Health Check Endpoint
+FAB-3388 - Operational metrics for Fabric components
+The peer and orderer have been instrumented to provide basic operational
+metrics. The metrics can be surfaced for consumption by Prometheus or StatsD.
 
+FAB-10851 - Health check endpoint
 The orderer and the peer now provide a mechanism to check the health of the
 process via an HTTP request. Requests to GET /healthz on the operations
 endpoint will complete with a status 200 OK when the server believes it is
 healthy. When a health check fails, the server will respond with a 503 Service
 Unavailable and a JSON payload indicating which component detected an issue.
 The types of health checks that are performed will be extended over time.
 
-FAB-12265 - Orderer Dynamic Log Levels
-
+FAB-12265 - Dynamic log levels
 The orderer and the peer now provide a mechanism to get and update the active
 logging specification of the server. Requests to GET /logspec on the
 operations endpoint will return with a JSON payload that contains the active
 spec. When a JSON payload of `{"spec":"the-log-spec"}` is sent as the body of
 a PUT /logspec request, the active logging spec will be updated.
 
-FAB-3388 - Operational Metrics for Fabric Components
-
-The peer and orderer have been instrumented to provide some basic operational
-metrics. The metrics can be surfaced for consumption by Prometheus or statsd.
+FAB-12357 - Updates to logging
+In earlier versions of Fabric, loggers were associated with named components
+and configuration would control the active level of each logger. While this
+model works in theory, because of the configuration management libraries used
+by Fabric and the structure of the Fabric code base, in practice it had a
+number of issues.
+With 1.4, we're changing the model slightly. Instead of associating loggers
+with components, we are naming loggers and to help avoid side effects during
+initialization, the logging configuration is no longer obtained from the
+fabric configuration system but from environment variables that define
+the logging specification and log format.
+The log specification is a single string that consists of colon separated
+tokens. Each token declares one or more logger name prefixes (separated by
+commas) and an optional log level. When the logger name prefix ends with a
+period, it indicates that the log level should only apply to the logger with
+that exact name without the trailing period. When the logger name pattern is
+omitted, it specifies the default log level. In cases where multiple entries
+reference the same name pattern or multiple instances of a default are
+provided, the last specification takes precedence.
 
-FAB-12372 - Obtain Go Routine Stacks Without Termination
+FAB-12363 - Logging for gRPC interactions
+The orderer and the peer now provide logging (INFO level) for each gRPC
+interaction completed.
 
+FAB-12372 - Obtain Go routine stacks without termination
 When SIGUSR1 is received by the peer or the orderer, the state of all go
 routines will be captured and logged at the INFO level. This collection
 activity will not terminate the process.
 
+FAB-5093 - Private data reconciliation
+Allows peers for organizations that are added to private data collections
+to retrieve the private data for prior transactions to which they now are
+entitled. This feature is only supported on peers that have joined
+a channel since v1.4.
+
+FAB-11409 - Private data client access control
+Ability to automatically enforce access control within chaincode based
+on the client organization collection membership without having to
+write specific chaincode logic. This feature is configured by using
+the collection configuration property memberOnlyRead:true. If you have
+a mixed network of v1.4 peers and prior release peers, the prior
+release peers will not honor this configuration until they are upgraded
+to v1.4.
+
+
 Changes, Known Issues, and Workarounds
 --------------------------------------
 
 FAB-12357 - Updates to logging
-
 Instead of using logging.level and CORE_LOGGING_LEVEL to control the logging
 level for the peer, and General.LogLevel or ORDERER_GENERAL_LOGLEVEL to
 control logging at the orderer, both processes now use the FABRIC_LOGGING_SPEC
 environment variable to acquire the initial logging specification for the
 server. Existing logging configuration should be converted to the new model.
 
 FAB-12489 - peer logging command updates
-
 The `getlevel`, `setlevel`, and `revertlevels` subcommands of the `peer
 logging` command are deprecated and users should migrate to the operations
 server.
-
 The behavior of `setlevel` has also changed slightly. The previous
 implementation would treat the `logger` argument as a regular expression and
 apply the new log level to all loggers that matched the expression. The
 updated implementation treats the `logger` argument as a logger name and
 appends it to the active logging spec at the indicated level.
 
+FAB-12088 - Java chaincode support on s390 architecture
+Java chaincode support is not yet available on s390 architecture.
+
+FAB-12134 Same chaincode source receiving fingerprint mismatch error
+Chaincode installed in different ways may result in "chaincode fingerprint
+mismatch data mismatch" error upon instantiation.  This may happen when
+installing chaincode by using different SDKs. To workaround the problem,
+package the chaincode prior to installation and instantiation, by using
+the "peer chaincode package" command.
+
+Known Vulnerabilities
+---------------------
+FAB-8664 - Peer should detect and react when its org has been removed
+This is a relatively low severity problem, because it requires a significant
+conspiracy of network admins, but it will be addressed in a future release.
+
+Resolved Vulnerabilities
+------------------------
+None.
+
+Other improvements and fixes
+----------------------------
+Updated to Go version 1.11.1
+Updated baseimage version to 0.4.14
+
+For the full list of improvements and fixes, refer to the release change log:
+https://github.com/hyperledger/fabric/blob/master/CHANGELOG.md#v140-rc1

scripts/bootstrap.sh

@@ -6,11 +6,11 @@
 #
 
 # if version not passed in, default to latest released version
-export VERSION=1.3.0
+export VERSION=1.4.0-rc1
 # if ca version not passed in, default to latest released version
 export CA_VERSION=$VERSION
 # current version of thirdparty images (couchdb, kafka and zookeeper) released
-export THIRDPARTY_IMAGE_VERSION=0.4.13
+export THIRDPARTY_IMAGE_VERSION=0.4.14
 export ARCH=$(echo "$(uname -s|tr '[:upper:]' '[:lower:]'|sed 's/mingw64_nt.*/windows/')-$(uname -m | sed 's/x86_64/amd64/g')")
 export MARCH=$(uname -m)
 
@@ -23,8 +23,8 @@ printHelp() {
   echo "-s : bypass fabric-samples repo clone"
   echo "-b : bypass download of platform-specific binaries"
   echo
-  echo "e.g. bootstrap.sh 1.3.0 -s"
-  echo "would download docker images and binaries for version 1.3.0"
+  echo "e.g. bootstrap.sh 1.4.0-rc1 -s"
+  echo "would download docker images and binaries for version 1.4.0-rc1"
 }
 
 dockerFabricPull() {