M12 release notes. (#806)

M12 release notes.

docs/source/changelog.rst

@@ -7,6 +7,9 @@ from the previous milestone release.
 UNRELEASED
 ----------
 
+Milestone 12.0 - First Public Beta
+----------------------------------
+
 * Quite a few changes have been made to the flow API which should make things simpler when writing CorDapps:
 
     * ``CordaPluginRegistry.requiredFlows`` is no longer needed. Instead annotate any flows you wish to start via RPC with
@@ -53,9 +56,6 @@ UNRELEASED
     * Names of parties are now stored as a ``X500Name`` rather than a ``String``, to correctly enforce basic structure of the
       name. As a result all node legal names must now be structured as X.500 distinguished names.
 
-* Flows can now accept ``PartyAndCertificate`` instead of ``Party`` in their constructor, which should be the default for
-  new flows. The sample flows have been updated to use ``PartyAndCertificate`` to illustrate this.
-
 * The identity management service takes an optional network trust root which it will validate certificate paths to, if
   provided. A later release will make this a required parameter.
 
@@ -68,9 +68,9 @@ UNRELEASED
        The ``ServiceHub.notaryIdentityKey`` has changed similarly. The goal of this change is to keep private keys
            encapsulated and away from most flow code/Java code, so that the private key material can be stored in HSMs
            and other key management devices.
-     * The ``KeyManagementService`` now provides no mechanism to request the node's ``PrivateKey`` objects directly.
+     * The ``KeyManagementService`` no longer provides any mechanism to request the node's ``PrivateKey`` objects directly.
        Instead signature creation occurs in the ``KeyManagementService.sign``, with the ``PublicKey`` used to indicate
-       which of the node's multiple keys to use. This lookup also works for ``CompositeKey`` scenarios
+       which of the node's keypairs to use. This lookup also works for ``CompositeKey`` scenarios
        and the service will search for a leaf key hosted on the node.
      * The ``KeyManagementService.freshKey`` method now returns only the ``PublicKey`` portion of the newly generated ``KeyPair``
        with the ``PrivateKey`` kept internally to the service.

docs/source/release-notes.rst

@@ -6,15 +6,48 @@ Here are release notes for each snapshot release from M9 onwards.
 Unreleased
 ----------
 
-Writing CorDapps has been made simpler by removing boiler-plate code that was previously required when registering flows.
+Milestone 12 - First Public Beta
-Instead we now make use of classpath scanning to automatically wire-up flows.
+--------------------------------
 
-There are major changes to the ``Party`` class as part of confidential identities, and how parties and keys are stored
+One of our busiest releases, lots of changes that take us closer to API stability (for more detailed information about
-in transaction state objects. See :doc:`changelog` for full details.
+what has changed, see :doc:`changelog`). In this release we focused mainly on making developers' lives easier. Taking
+into account feedback from numerous training courses and meet-ups, we decided to add ``CollectSignaturesFlow`` which
+factors out a lot of code which CorDapp developers needed to write to get their transactions signed.
+The improvement is up to 150 fewer lines of code in each flow! To have your transaction signed by different parties, you
+need only now call a subflow which collects the parties' signatures for you.
 
-We've added the ability for flows to be versioned by their CorDapp developers. This enables a node to support a particular
+Additionally we introduced classpath scanning to wire-up flows automatically. Writing CorDapps has been made simpler by
-version of a flow and allows it to reject flow communication with a node which isn't using the same fact. In a future
+removing boiler-plate code that was previously required when registering flows. Writing services such as oracles has also been simplified.
-release we allow a node to have multiple versions of the same flow running to enable backwards compatibility.
+
+We made substantial RPC performance improvements (please note that this is separate to node performance, we are focusing
+on that area in future milestones):
+
+- 15-30k requests per second for a single client/server RPC connection.
+  * 1Kb requests, 1Kb responses, server and client on same machine, parallelism 8, measured on a Dell XPS 17(i7-6700HQ, 16Gb RAM)
+- The framework is now multithreaded on both client and server side.
+- All remaining bottlenecks are in the messaging layer.
+
+Security of the key management service has been improved by removing support for extracting private keys, in order that
+it can support use of a hardware security module (HSM) for key storage. Instead it exposes functionality for signing data
+(typically transactions). The service now also supports multiple signature schemes (not just EdDSA).
+
+We've added the beginnings of flow versioning. Nodes now reject flow requests if the initiating side is not using the same
+flow version. In a future milestone release will add the ability to support backwards compatibility.
+
+As with the previous few releases we have continued work extending identity support. There are major changes to the ``Party``
+class as part of confidential identities, and how parties and keys are stored in transaction state objects.
+See :doc:`changelog` for full details.
+
+Added new Byzantine fault tolerant (BFT) decentralised notary demo, based on the `BFT-SMaRT protocol <https://bft-smart.github.io/library/>`_
+For how to run the demo see: :ref:`notary-demo`
+
+We continued to work on tools that enable diagnostics on the node. The newest addition to Corda Shell is ``flow watch`` command which
+lets the administrator see all flows currently running with result or error information as well as who is the flow initiator.
+Here is the view from DemoBench:
+
+.. image:: resources/flowWatchCmd.png
+
+We also started work on the strategic wire format (not integrated).
 
 Milestone 11
 ------------

docs/source/running-the-demos.rst

@@ -111,6 +111,8 @@ To run from the command line in Windows:
 4. Run ``gradlew samples:attachment-demo:runSender`` in another terminal window to send the attachment. Now look at the other windows to
    see the output of the demo
 
+.. _notary-demo:
+
 Notary demo
 -----------