Prepare/v1.3.0.1 (#1046)

Combines:
* A merge of `main` into `release/cuttlefish`
* A bump of the version in the docker file
* The content of `v1.3.0.1`

To be merged into `release/cuttlefish` for preparation of `v1.3.0.1`.

Author: dhedey

.github/pull_request_template.md

@@ -1,29 +1,35 @@
 > [!IMPORTANT]
 >
-> * Please read our [Contributing Guidelines](https://github.com/radixdlt/babylon-node/blob/main/CONTRIBUTING.md) before opening a PR.
-> * Before creating your PR, please ensure you have used the _correct base branch_ as per the [branching strategy](https://github.com/radixdlt/babylon-node/blob/main/docs/branching-strategy.md), both for branching from, and in the PR UI above.
->   * For most code changes, this is `develop`.
->   * For stand-alone docs changes, this is `main`.
->   * For workflow changes, this is the oldest supported `release/*` branch. 
-> * Please remove these sections as you fill out your PR.
+> * Please read our [Contributing Guidelines](/CONTRIBUTING.md) before opening a PR.
+> * Before creating your PR, please ensure you read the [branching strategy](/docs/branching-strategy.md). The end result after completing the merge actions should be that `main <= release/XXX <= develop`, where `XXX` is the latest released protocol version. This ensures that we minimise merge conflicts, and that work doesn't go missing.
+> * As per the branching strategy, **you must ensure you select the _correct base branch_**, both for branching from, and in the PR UI above. The following process can be used to decide the base branch:
+>   * For code changes which can wait until the next protocol update to be released, use `develop`. This should be the default for code changes.
+>   * For code changes which need to go out as a fully-interoperable update to the node at the current protocol version, use `release/XXX`.
+>     * Such changes must be tested and reviewed more carefully to mitigate the risk of regression.
+>     * Once the change is merged, it is the merger's responsibility to ensure `release/XXX` is merged into the `develop` branch.
+>   * For github workflow changes, use `main`.
+>     * Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop`, so that the changes also apply to hotfixes, and to current development.
+>   * For changes to README files, use `main`.
+>     * Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop`, so that the changes also apply on these branches.
 > 
+> _Please remove this section once you confirm you follow its guidance._
 
 ## Summary
 
+<!--
 > [!TIP]
 > 
 > Start with the context of your PR. Why are you making this change? What does it address? Link back to an issue if relevant.
 > 
-> Then summarise the changes that were made. Bullet points are fine.
-
-## Details
-
-> [!TIP]
-> 
-> This section is optional. Go into more detail about the changes that were made, or the thinking behind the changes.
+> Then summarise the changes that were made.
+> * Bullet points are fine.
+> * Feel free to add additional subheadings (using ###) with more information if required.
+-->
 
 ## Testing
 
+<!--
 > [!TIP]
 > 
 > Explain what testing / verification is done, including manual testing or automated testing.
+-->

docs/branching-strategy.md

@@ -3,67 +3,62 @@
 
 Once you have read the [contributing guide](../CONTRIBUTING.md), if you want to start development, you will need to know which branches to use.
 
-> [!NOTE]
-> Supported base branches:
-> * `develop` - The primary development branch for upcoming features and enhancements
-> * `release/*` - Various past and future releases
-> * `main` - A mirror of the latest release
-> 
-> When clicking merge on a PR to one of these branches, it is your duty to ensure that PRs are raised to merge that branch into all later/downstream supported base branches.
-
-## Summary of approach
-
-### The base branches
-
 We use a variant of `git-flow`, where there are three types of base branches: the `main`, `develop`, and `release/*` branches.
 
-* The `main` branch is the public-facing base branch and **represents the last official release**. It's also used for docs.
-* The `develop` branch is the primary integration branch, for work targeting the next protocol version.
-* The `release/*` branches are for all named protocol versions (i.e. each 1.X in the naming scheme. Typically patch releases should re-use same branch). A subset of release branches are **currently supported** - typically these are those currently on a live environment, or under development.
-
-At any given time, there is a strict ordering on the supported base branches, where the process aims to guarantee all work on previous branches is in the later/downstream branches. This order (from earliest/most upstream to latest/most downstream) is as follows:
-
-* Released `release/*` branches still compatibile with a mainnet network
-* `main`
-* Unreleased `release/*` branches
-* `develop`
-
-The latest ordering is at the top of this document.
+> [!IMPORTANT]
+> The currently supported base branches are as follows:
+> * `develop` - The primary development branch for features and enhancements to be released at the next protocol version.
+> * `release/XXX` = `release/cuttlefish` - The latest published protocol version. This is used for hotfixes or low-risk protocol-compatible changes which will be released as an optional node update.
+> * `main` - The public-facing base branch, which represents the docs and code for the latest official release.
+>
+> This list is ordered by "each branch should contain every change in each branch below it". When clicking merge on a PR to one of these base branches `B`, it is your duty to ensure that a new PR is raised to merge `B` into all branches above `B` in the list. This ensures that work ends up in the right place, we minimise merge conflicts, and that work doesn't go missing. See the [Development and Merge Process](#developmentmerge-process) section for more information.
 
-### Development process
+## Development/Merge process
 
 When working on changes:
-* You will first need to select the correct base branch to create your feature branch from. For some epics, it is acceptable to choose a long running `feature/*` or `epic/*` branch as your base, to break up the work into separate reviews.
+* You will first need to select the correct base branch to create your feature branch from. For some epics, it is acceptable to choose a long running `feature/*` or `epic/*` branch as your base, to break up the work into separate reviews, but to merge it atomically once it's been properly tested.
 * Your branch should start `feature/*`, or variants on naming such as `hotfix/*`, `tweak/*`, `docs/*` are permitted. The specific name should be prefixed by a JIRA ticket or Github issue reference where appropriate, e.g. `feature/NODE-123-my-feature` for JIRA tickets or `feature/gh-1235-my-feature` for github issues.
 * When you raise a PR, you will need to ensure you select the appropriate base branch before creating the PR. **The default, `main` is typically not correct!**
 
-> [!IMPORTANT]
-> 
-> Finally, when a PR is merged, it is **the PR merger's responsibility** to ensure that the _base branch_ that was merged into is then merged into _all downstream base branches_ (ideally one by one, like a waterfall).
->
-> If there is a merge conflict, this should be handled by creating a special `conflict/X-into-Y-DATE` branch (for branches `X`, `Y` and `DATE`) from `X`, and putting in a PR with a merge target of `Y`.
->
-> But if this process is properly followed, such merge conflicts will be rare. 
+Finally, when a PR is merged, it is **the PR merger's responsibility** to ensure that the _base branch_ that was merged into is then merged into _all downstream base branches_. If there is a merge conflict, this should be handled by creating a special `conflict/X-into-Y-DATE` branch (for branches `X`, `Y` and `DATE`) from `X`, and putting in a PR with a merge target of `Y`. If this process is properly followed, such merge conflicts will be rare. 
 
-## Which base branch should I use for X?
+## Which base branch should I use for my change?
 
 ### Code changes
 
-Features branches usually branch from `develop`, unless they need to target the current/previous protocol version, in which case, they will need to target the appropriate `release/*` branch.
+For most code changes, choose `develop`. Code against the `develop` branch will be released at the next protocol update.
 
-### Stand-alone doc changes
+For code changes which need to go out as a fully-interoperable update to the node at the current protocol version, use the current `release/XXX` branch. Such changes will be reviewed more carefully to mitigate the risk of regression. Once the change is merged, it is the merger's responsibility to ensure `release/XXX` is merged into the develop branch.
 
-Public facing docs change unrelated to another ticket should use a base branch of `main` - as this is the branch which is first visible when someone looks at the repository.
+### Stand-alone README changes
+
+Public facing docs change unrelated to another ticket should use a base branch of `main` - as this is the branch which is first visible when someone looks at the repository. Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop` branches to avoid merge conflicts or confusion.
 
 ### Workflow / CI changes
 
-Workflow changes should branch from the _most upstream_ (earliest) supported branch. Typically this is a `release/*` branch.
+For github workflow changes, start by branching off of and merging to the current `main` branch.
+
+Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop`, so that the changes also apply for current development, and for any hotfixes which need to be built and release.
+
+## Base branch change process
 
-Once the post-merge process is followed, this change will find itself on all later/downstream base branches too.
+* When a release is published, as part of the release process, `release/XXX` will get merged into `main`, which should effectively set `main == release/XXX`.
+* When a new protocol update is about to be published, late in the process:
+  * A `release/YYY` branch will be created from `develop`
+  * Any existing PRs will be reviewed and either have their base branch adjusted to `release/YYY` or kept against `develop`
+  * The active branch at the top of this file will be updated to `release/YYY`
 
-This ensures that these changes are on all supported branches, so builds can be built on `develop` or on all supported branches.
+## Background Detail
 
-## Merge or Rebase/Cherry-pick?
+### Diagram
+
+The following demonstrates a possible branch structure under this strategy, under the hypothetical scenario where `bottlenose` is the current live protocol version, and `cuttlefish` is being prepared but not yet live.
+
+Admittedly, this isn't particularly easy to follow. The key with this strategy is following the rules. If the rules are followed, you don't need to visualize the structure.
+
+![Diagram summarising the branching strategy](./branching-diagram.png)
+
+### Merge or Rebase/Cherry-pick?
 
 This strategy relies on the fact that we always merge.
 
@@ -77,15 +72,7 @@ We acknowledge the weakness of merging that this can make the git history messie
 
 At merge time, it is acceptable but not recommended to squash-merge. We encourage developers to instead squash commits before asking for a review. This results in a better record of the review / iteration process.
 
-## Diagram
-
-The following demonstrates a possible branch structure under this strategy, under the hypothetical scenario where `bottlenose` is the current live protocol version, and `cuttlefish` is being prepared but not yet live.
-
-Admittedly, this isn't particularly easy to follow. The key with this strategy is following the rules. If the rules are followed, you don't need to visualize the structure.
-
-![Diagram summarising the branching strategy](./branching-diagram.png)
-
-## Why do we follow this model?
+### Why do we follow this model?
 
 In order to support a network built upon deterministic execution of the radix engine, we need to have a very clear policy of what is compatible with what. This is where the protocol version strategy comes in. And this maps to git via the `release/*` branch strategy.
 

testnet-node/docker-compose.yml

@@ -4,7 +4,7 @@ services:
   core:
     container_name: radixdlt-stokenet-node
     #### Chose to either uncomment "image" or "build" to either pull the image from dockerhub or build locally from source
-    image: radixdlt/babylon-node:v1.3.0
+    image: radixdlt/babylon-node:v1.3.1
     # build:
     #   context: ..
     #   dockerfile: Dockerfile