Fix ambiguous instructions in release process

docs/build-and-release-guide.md

@@ -137,7 +137,7 @@ Checklist for the release,
 5. Run the release workflow.
 6. Publish artifact to the [Central Dev Environment](https://github.com/ballerina-platform/module-ballerina-http/actions/workflows/central-publish.yml). Select the `DEV CENTRAL` option in the workflow.
 7. Update module version in Ballerina Distribution in the corresponding patch branch.
-   
+
    > **Note:** If the module is released while updating one or more ballerina library dependencies, then make sure those versions are also updated in the Ballerina distribution repository.
 8. Merge the automated post-release pull request in the respective module repo to the corresponding patch branch (E.g.: If the release is done on top of the 2201.3.x branch, change the pull request base to 2201.3.x branch and then merge the PR).
 
@@ -172,11 +172,9 @@ The Ballerina Library Release Manager will use [Library Release](https://github.
     - Do not remove `ballerina-distribution` from the [extensions.json](https://github.com/ballerina-platform/ballerina-release/blob/master/dependabot/resources/extensions.json). If removed, the workflow will not update latest stdlib versions in `ballerina-distribution` in master branch
 4. Ensure Ballerina Release Manager has released all modules to the Central Staging after each RC vote. The release Manager of the Ballerina Release will publish this. Module owners are responsible for the ballerinax components.
 5. The Ballerina library release manager runs the [stdlib test workflow](https://github.com/ballerina-platform/ballerina-library/actions/workflows/test_stdlib_releases_with_staging.yml) to verify newly published modules are working in an integration scenario. (This is to ensure no Ballerina library release will break the existing users' build)
-6. Once the final RC pack is passed the voting phase, update the [module list](https://github.com/ballerina-platform/ballerina-standard-library/blob/main/release/resources/stdlib_modules.json) to reflect the modules to be released.
-   >**Note:** If a module is not releasing with the given distribution release, change the `release` property to `false` in the module list. (This can be done on a separate branch and that branch can be used to trigger the release workflow.)
+6. Once the final RC pack is passed the voting phase, create a separate branch in the `ballerina-library` repo related to the release and, update the [`stdlib_modules.json`](https://github.com/ballerina-platform/ballerina-standard-library/blob/main/release/resources/stdlib_modules.json) file by either setting the `release` property to `false` or completely removing the entries for the modules that don't need to be released.
 7. Once the module list is updated, notify the team to refrain from merging any PRs to the default branches, including the post-release PRs.
-8. Create a separate branch in the `ballerina-library` repo related to the release and, update the `stdlib_modules.json` file by either setting the `release` property to `false` or completely removing the entries for the modules that don't need to be released.
-9. Then the release manager can trigger the [Library Release Workflow](https://github.com/ballerina-platform/ballerina-library/actions/workflows/release_pipeline.yml) to trigger the release.
+8. Then the release manager can trigger the [Library Release Workflow](https://github.com/ballerina-platform/ballerina-library/actions/workflows/release_pipeline.yml) to trigger the release.
     This workflow expects the following inputs:
     - `release_libs`: To release the library (`module-ballerina-*` modules that are packed with the distribution) modules. These modules are listed under the `modules` field in the `module_list.json` file. The default value is `true`.
     - `release_extensions`: To release the ballerina extended (`module-ballerinax-persist.*`, and `copybook`) modules. These modules are listed under the `extended_modules` field in the `module_list.json` file. The default value is `false`.
@@ -186,7 +184,7 @@ The Ballerina Library Release Manager will use [Library Release](https://github.
 
     > **Note:** When the connectors needed to be released at once, it is advised to release them separately, after releasing the library modules. This is because most probably the connectors has to be released once the Ballerina distribution is released.
 
-10. The workflow logs will show the current status of the release. The release manager should monitor the workflow and take necessary actions if any failures occur.
+9. The workflow logs will show the current status of the release. The release manager should monitor the workflow and take necessary actions if any failures occur.
 
     - If a particular module release is failed, the Ballerina library release manager should check the logs and take necessary actions to fix the issue.
       - If the issue is related to the module, inform the module owner to fix the issue and inform the release manager.
@@ -195,5 +193,5 @@ The Ballerina Library Release Manager will use [Library Release](https://github.
     - Once the failed module is released, the Ballerina library release manager can re-trigger the Library Release Workflow to continue the release. There's no need to update the module list.
 
        >**Note:** If a post-release sync PR is merged before the release is completed, re-triggering the workflow may result in a re-release of the module.
-11. Once the release workflow is complete, update the corresponding branch in the `ballerina-distribution` repo with the released module versions. Then inform the release manager to continue the distribution release process.
-12. Once the distribution release process is completed, notify the team to update the changelogs and merge the post-release PRs to the default branches.
+10. Once the release workflow is complete, update the corresponding branch in the `ballerina-distribution` repo with the released module versions. Then inform the release manager to continue the distribution release process.
+11. Once the distribution release process is completed, notify the team to update the changelogs and merge the post-release PRs to the default branches.