d9e11b21ae
In Corda 4, FinalityFlow was updated to become an initiated flow, in order to ensure a node does not have to accept any signed transaction it receives without being able to check it first. The old behaviour of FinalityFlow was gated behind a targetPlatformVersion check, to prevent apps targeting V4 from using the old behaviour. This is problematic for a few reasons. For an app wishing to be backwards compatible with a version running on V3, this forces the app to set targetPlatformVersion = 3, even if the app is thoroughly tested against V4. This goes against the purpose of the targetPlatformVersion. Another consequence is that an app remains pinned to targetPlatformVersion = 3 until it is sure that there are no other apps running at a lower version in the network, which would prevent newer versions of the app from taking advantage of features gated behind targetPlatformVersion checks. (Note that the restriction only prevents a new version of the app from initiating FinalityFlow with the old version - the old version is able to initiate a FinalityFlow and the new version will handle it, assuming the app has been written correctly.) This fix removes the targetPlatformVersion check from FinalityFlow, and also provides a few documentation updates to clarify what level of testing would be expected to set a targetPlatformVersion.
Corda Documentation Build
To run the Corda Documentation build run ./gradlew makeDocs
Note: In order to run the documentation build you will need Docker installed.
Windows users: If this task fails because Docker can't find make-docsite.sh, go to Settings > Shared Drives in the Docker system tray agent, make sure the relevant drive is shared, and click 'Reset credentials'.
rst style guide
It's probably worth reading this to get your head around the rst syntax we're using.
version placeholders
Currently we support five placeholders that get substituted at build time:
"|corda_version|"
"|java_version|"
"|kotlin_version|"
"|gradle_plugins_version|"
"|quasar_version|"
If you put one of these in an rst file anywhere (including in a code tag) then it will be substituted with the value in constants.properties (which is in the root of the project) at build time.
The code for this can be found near the top of the conf.py file in the docs/source directory.