docs: update doc (#132)

* docs: update doc * refactor: apply suggestions Co-authored-by: wwared <[email protected]> * refactor: second batch of suggestion Co-authored-by: wwared <[email protected]> --------- Co-authored-by: wwared <[email protected]>
argumentcomputer · Jul 30, 2024 · 210218a · 210218a
1 parent 83525f6
commit 210218a
Show file tree

Hide file tree

Showing 3 changed files with 9 additions and 9 deletions.
diff --git a/aptos/docs/src/components/client.md b/aptos/docs/src/components/client.md
@@ -21,4 +21,4 @@ the proofs generation in parallel. This flow happens during initialization where
 Aptos network while producing an inclusion proof for a given account at the latest block.
 
 The bundled example client currently only requests and verifies STARK proofs. The proof servers have support for generating
-and verifying SNARK proofs, but the example client does not yet make use of this.
+and verifying SNARK proofs, but the example client does not yet make use of this.
diff --git a/aptos/docs/src/design/overview.md b/aptos/docs/src/design/overview.md
@@ -26,7 +26,7 @@ to some account needs to be validated.
 The current Verifying Key Hashes which uniquely identify the specific RISC-V binaries for the proof programs, located in the
 [`aptos/aptos-programs/artifacts/`](https://github.com/lurk-lab/zk-light-clients/tree/dev/aptos/aptos-programs/artifacts)
 directory are:
-* `epoch_change`: `0x00eea0650222f7e5bb6a2fe57c0e0e504d1df8b3d848d5116174a8703d228c94`
+* `epoch_change`: `0x008f0133dc5a02eb31ac769e9e3a2f34da1af34c963bf3ee9a058982a2978cc9`
 * `inclusion`: `0x00336c570224c00161ca7b3c275c24f3968aa09086c31d09d98691bce109f4f6`
 
-These values are also present in and used by the [solidity fixtures](../benchmark/on_chain.md).
+These values are also present in and used by the [solidity fixtures](../benchmark/on_chain.md).
diff --git a/aptos/docs/src/misc/release.md b/aptos/docs/src/misc/release.md
@@ -8,29 +8,29 @@ run it.
 The release process is mostly automated through the usage of GitHub Actions.
 
 A release should be initiated through the manually triggered GitHub Action **Bump Version**. When triggering a release,
-the reference base that should be chosen is the `dev` branch, with a `release` type and the desired release version. The
+the reference base that should be chosen is the `dev` branch, with a `release` type, `aptos` light-client and the desired release version. The
 specified release version should follow [the Semver standard](https://semver.org/).
 
-This action opens a new PR from a branch named `release/<release-version>` with `dev` as its base. A commit is
+This action opens a new PR from a branch named `release/aptos-v<release-version>` with `dev` as its base. A commit is
 automatically applied to bump all the `Cargo.toml` version of the relevant crates. The developer in charge of the
 release should use this branch to make any necessary updates to the codebase and documentation to have the release
 ready.
 
 Once all the changes are done, the PR can be squash and merged in `dev`. This will trigger the **Tag release** action
-that is charged with the publication of a release and a tag named `<release-version>`.
+that is charged with the publication of a release and a tag named `v<release-version>`.
 
 ## Hotfix process
 
 The hotfix process is quite similar to the release one.
 
-**Bump Version** should also be triggered, but with the desired `release/<release-to-fix>` as reference. A PR will be
-opened from a branch named `hotfix/<hotfix-version>` with the base `release/<release-to-fix>`. A commit is automatically
+**Bump Version** should also be triggered, but with the desired `release/aptos-v<release-to-fix>` as reference. A PR will be
+opened from a branch named `hotfix/aptos-v<hotfix-version>` with the base `release/aptos-v<release-to-fix>`. A commit is automatically
 applied to bump all the `Cargo.toml` version of the relevant crates. The developer in charge of the
 hotfix should use this branch to make any necessary updates to the codebase and documentation to have the hotfix
 ready.
 
 Once all the changes are done, the PR can be squash and merged in `release/<release-to-fix>`. This will trigger the
-**Tag release** action that is charged with the publication of a release and a tag named `<hotfix-version>`.
+**Tag release** action that is charged with the publication of a release and a tag named `v<hotfix-version>`.
 
 Finally, the developer will also need to port the changes made to `dev` so that they are reflected on the latest
 development stage of the Light Client.