Release 0.81.0

Termination is no longer used for authorizing contract migrations

This means that if you used CSLFlows.terminateContractFlow prior to running CSLFlows.migrateContractFlow you should now call CSLFlows.authorizeContractMigrationFlow instead.

Similarly, CSLFlows.terminateContractFlow no longer accepts a TerminationIntent.Migrate and this type has also been replaced by MigrationSpec which is structurally the same as TerminationIntent.Migrate.

Since termination is no longer overloaded to also act as migration authorization, the TerminationIntent type has been deleted.

CSLFlows signature changed

This change is only relevant if you use custom CSL Flows. The CSLFlows interface has changed the signature of its methods, so they no longer take an ops: CordaRPCOps along with constructor arguments to the flows and return FlowHandle<T>. Instead, they now only receive the constructor arguments and return an instance FlowDispatch<T>.

Migration is a mechanical task.

For example:

object CustomCSLFlows : CSLFlows by DefaultCSLFlows {
    override fun executeOperationsFlow(
        ops: CordaRPCOps,
        operationSequences: List<ContractOperationSequence>,
        attachmentId: SecureHash,
        partiesAndNotary: PartiesAndNotary?
    ): FlowHandle<List<ContractOperationSequenceResult>> =
        ops.startFlow(::CustomExecuteOperationsFlow, operationSequences, attachmentId, partiesAndNotary)

    override fun executeOperationsResponderFlow(ops: CordaRPCOps, otherSide: FlowSession): FlowHandle<Unit> =
        ops.startFlow(::CustomExecuteOperationsResponderFlow, otherSide)
}

becomes

object CustomCSLFlows : CSLFlows by DefaultCSLFlows {
    override fun executeOperationsFlow(
        operationSequences: List<ContractOperationSequence>,
        attachmentId: AttachmentId,
        partiesAndNotary: PartiesAndNotary?
    ): FlowDispatch<List<ContractOperationSequenceResult>> =
        flowDispatch(::CustomExecuteOperationsFlow, operationSequences, attachmentId, partiesAndNotary)
}

by changing the return type, removing the ops param and calling flowDispatch instead of ops.startFlow.

Changed custom CSLContractState.createContractState factory method to receive an instance of DefaultCSLContractState

If you need to use custom built-ins in your CSL code, you have to provide your own implementation of CSLContractState for the sole purpose of selecting your custom CSLTransactionVerifier during transaction verification.

The easiest way is to make a simple wrapper around DefaultCSLContractState, but given the signature of CSLCordappConfiguration.createContractState this was difficult.

To make this process easier, the signature of CSLCordappConfiguration.createContractState has been changed to receive an instance of DefaultCSLContractState instead of receiving all the fields separately.

Contract migrations yield a new contract version with Migrated provenance instead of Instantiated

This makes it easier to spot when a contract was in fact migrated instead of being instantiated.