ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-02-21 01:42:24 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Add draft release notes for M9

Browse Source
This commit is contained in:
Ross Nicoll 2017-03-02 10:27:50 +00:00
parent caea578093
commit 285479a963
3 changed files with 64 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/source/index.rst
View File

@ -125,6 +125,7 @@ Documentation Contents:
setting-up-a-corda-network
secure-coding-guidelines
release-process
release-notes
changelog
codestyle
building-the-docs

49
docs/source/release-notes.rst Normal file
View File

@ -0,0 +1,49 @@
Release notes
=============
Here are release notes for each snapshot release from M9 onwards. This includes guidance on how to upgrade code from
the previous milestone release.
Milestone 9
-----------
This release focuses on improvements to resiliency of the core infrastructure, with highlights including a Byzantine
fault tolerant (BFT) decentralised notary, based on the BFT-SMaRT protocol and isolating the web server from the
Corda node.
With thanks to open source contributor Thomas Schroeter for providing the BFT notary, Corda can now resist malicious
attacks by members of a distributed notary service. If your notary has five members, two can become hacked or malicious
simultaneously and the system continues unaffected!
.. You can read more about this new feature <here>.
The web server has been split out of the Corda node as part of our ongoing hardening of the node. We now provide a Jetty
servlet container pre-configured to contact a Corda node as a backend service out of the box, which means individual
webapps can have their REST APIs configured for the specific security environment of that app without affecting the
others, and without exposing the sensitive core of the node to malicious Javascript.
We have launched a global training programme, with two days of classes from the R3 team being hosted in London, New York
and Singapore. R3 members get 5 free places and seats are going fast, so sign up today.
We've started on support for confidential identities, based on the key randomisation techniques pioneered by the Bitcoin
and Ethereum communities. Identities may be either anonymous when a transaction is a part of a chain of custody, or fully
legally verified when a transaction is with a counterparty. Type safety is used to ensure the verification level of a
party is always clear and avoid mistakes. Future work will add support for generating new identity keys and providing a
certificate path to show ownership by the well known identity.
There are even more privacy improvements when a non-validating notary is used; the Merkle tree algorithm is used to hide
parts of the transaction that a non-validating notary doesn't need to see, whilst still allowing the decentralised
notary service to sign the entire transaction.
The serialisation API has been simplified and improved. Developers now only need to tag types that will be placed in
smart contracts or sent between parties with a single annotation... and sometimes even that isn't necessary!
Better permissioning in the cash CorDapp, to allow node users to be granted different permissions depending on whether
they manage the issuance, movement or ledger exit of cash tokens.
We've continued to improve error handling in flows, with information about errors being fed through to observing RPC
clients.
There have also been dozens of bug fixes, performance improvements and usability tweaks. Upgrading is definitely
worthwhile and will only take a few minutes for most apps.
For a full list of changes please see :doc:`change-log`.

24
docs/source/release-process.rst
View File

@ -28,17 +28,21 @@ Steps to cut a release
1. Pick a commit that is stable and do basic QA: run all the tests, run the demos.
2. Review the commits between this release and the last looking for new features, API changes, etc. Make sure the
summary in the current section of the :doc:`changelog` is correct and update if not. Then move it into the right
section for this release. This is the right place to put any advice on how to port app code from the last release.
3. Additionally, if there are any new features or APIs that deserve a new section in the docsite and the author didn't
section for this release.
3. Write up a summary of the changes for the :doc:`release-notes`. This should primarily be suited to a semi-technical
audience, but any advice on how to port app code from the previous release, configuration changes required, etc.
should also go here.
4. Additionally, if there are any new features or APIs that deserve a new section in the docsite and the author didn't
create one, bug them to do so a day or two before the release.
4. Regenerate the docsite if necessary and commit.
5. Create a branch with a name like `release-M0` where 0 is replaced by the number of the milestone.
6. Adjust the version in the root build.gradle file to take out the -SNAPSHOT and commit it on the branch.
7. Remove the "is master" warning from the docsite index page on this branch only.
8. Tag the branch with a tag like `release-M0.0`
9. Push the branch and the tag to git.
10. Write up a short announcement containing the summary of new features, changes, and API breaks. Send it to the r3dlg-awg mailing list.
11. On master, adjust the version number in the root build.gradle file upwards.
5. Regenerate the docsite if necessary and commit.
6. Create a branch with a name like `release-M0` where 0 is replaced by the number of the milestone.
7. Adjust the version in the root build.gradle file to take out the -SNAPSHOT and commit it on the branch.
8. Remove the "is master" warning from the docsite index page on this branch only.
9. Tag the branch with a tag like `release-M0.0`
10. Push the branch and the tag to git.
11. Write up a short announcement containing the summary of new features, changes, and API breaks.
This can often be derived from the release notes. Send it to the r3dlg-awg mailing list.
12. On master, adjust the version number in the root build.gradle file upwards.
If there are serious bugs found in the release, backport the fix to the branch and then tag it with e.g. `release-M0.1`
Minor changes to the branch don't have to be announced unless it'd be critical to get all developers updated.