docs: Prepare documentation for FireFly v1.3.0 #1461
Conversation
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: SamMayWork <[email protected]>
docs/releasenotes/index.md
Outdated
| @@ -9,6 +9,18 @@ has_children: true | |||
|
|
|||
| [Full release notes](https://github.com/hyperledger/firefly/releases) | |||
|
|
|||
| ## [v1.3.0 - February XX, 2024](https://github.com/hyperledger/firefly/releases/tag/v1.1.0) | |||
There was a problem hiding this comment.
Reminder to update this before release 🚀
Signed-off-by: SamMayWork <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1461 +/- ##
==========================================
- Coverage 99.99% 99.99% -0.01%
==========================================
Files 322 322
Lines 23406 23301 -105
==========================================
- Hits 23404 23299 -105
Misses 1 1
Partials 1 1 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
This is a great start! Thank you so much for putting this together.
I realize there are a couple of features you may not have seen yet, but I think we need to add more details on:
- The new multiparty contract
- The ability to send messages / pin data with custom contract invocations
| ## API definition/publication considerations | ||
|
|
||
| **As of FireFly v1.3.0, by default, contract interfaces, contracts APIs, and token pools are unpublished when they are created.** |
There was a problem hiding this comment.
Two notes that I think should be added here:
- This only applies to multiparty namespaces
- This is a new feature, and I think the way we describe it should highlight the increased flexibility that it provides. We have differentiated creating a resource and publishing it, giving users more control over how and when data is shared in a multiparty namespace
There was a problem hiding this comment.
On these points I've opted for a slight-rewrite in this commit c137e9d, will request a re-review when we're in a good place.
|
|
||
| In FireFly v1.2.0 to create one of the affected resources and publish it to other parties, a `POST` call would be made to its respective API route and the broadcast would happen immediately. To achieve the same behaviour in FireFly v1.3.0, there are 2 options for all impacted resources, either providing a query parameter at creation to signal immediate publish, or a subsequent API call to publish the resources. | ||
|
|
||
| > **NOTE**: All of the impacted resources can be deleted locally using `DELETE` APIs, however, once the resources has been published, it is no longer possible to delete. |
There was a problem hiding this comment.
This is actually a pretty important new feature which I think should be highlighted a bit more prominently. Previously, if you made a mistake when creating a token pool (as an example) you could not create another one with the same name, etc so you were stuck with a broken REST resource. Now you have a chance to create it and use it on your FireFly node before publishing it and pinning it to the blockchain.
There was a problem hiding this comment.
On these points I've opted for a slight-rewrite in this commit c137e9d, will request a re-review when we're in a good place.
|
|
||
| Event streams now follow the format `<plugin_topic_name>/<namespace_name>`. For example, an event stream for the default namespace with a plugin topic of 0 would now be: `0/default`. | ||
|
|
||
| [For an exact view of the changes, see PR #1388.](https://github.com/hyperledger/firefly/pull/1388) |
There was a problem hiding this comment.
Two other notes here that should be added:
- The migration from FireFly 1.2.x -> 1.3 will result in a rebuilding of the existing event streams. This means that connectors will replay past events to FireFly, but FireFly will automatically de-duplicate them by design so this is a safe operation.
- These changes should result in no impact to end users of FireFly. They are merely noted here in the release notes because they are a significant architectural change to the relationship between namespaces, plugins, and connectors.
There was a problem hiding this comment.
Restructured with changes in c0b0901
docs/releasenotes/index.md
Outdated
| What's New: | ||
|
|
||
| - Namespaces now have individual event streams | ||
| - Contract listeners now support having multiple filters |
There was a problem hiding this comment.
I'm not sure if this one is going to make the cut
docs/releasenotes/index.md
Outdated
|
|
||
| What's New: | ||
|
|
||
| - Namespaces now have individual event streams |
There was a problem hiding this comment.
Not sure I would list this one first. It's not a very exciting feature to the end-user.
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: SamMayWork <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
Signed-off-by: Nicko Guyer <[email protected]>
| @@ -104,8 +124,14 @@ See the [README](https://github.com/hyperledger/firefly-tokens-erc20-erc721/blob | |||
| You can pass a `config` object with an `address` and `blockNumber` when you make the request to create the token pool, and if you created a contract interface, you can include the `interface` ID as well. | |||
|
|
|||
| #### Request | |||
| <<<<<<< HEAD:docs/tutorials/tokens/erc721.md | |||
There was a problem hiding this comment.
There is a merge conflict there that needs fixing
| @@ -52,6 +71,7 @@ If you're using the default ERC-20 / ERC-721 token connector and its sample toke | |||
| "type": "token_pool", | |||
| "id": "00678116-89d2-4295-990c-bd5ffa6e2434" | |||
| } | |||
| >>>>>>> main:doc-site/docs/tutorials/tokens/erc721.md | |||
| @@ -28,8 +28,14 @@ After your stack is up and running, the first thing you need to do is create a t | |||
| If you're using the default ERC-20 / ERC-721 token connector and its sample token factory, it will automatically deploy a new ERC-721 contract instance. | |||
|
|
|||
| #### Request | |||
| <<<<<<< HEAD:docs/tutorials/tokens/erc721.md | |||
Signed-off-by: Nicko Guyer <[email protected]>
For 1.3 this contains the migration guide, along with updates to tutorials and docs to match the breaking changes going into this release. Do shout if there's anything I've missed