Skip to content

Commit

Permalink
Prepare/v1.3.0.1 (#1046)
Browse files Browse the repository at this point in the history 
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`.
  • Loading branch information
@dhedey
dhedey authored Jan 3, 2025
2 parents 46be634 + ffca280 commit 47da8a8
Show file tree
Hide file tree
Showing 3 changed files with 57 additions and 64 deletions.
32 changes: 19 additions & 13 deletions .github/pull_request_template.md
View file
Original file line number Diff line number Diff line change
@@ -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.
-->
87 changes: 37 additions & 50 deletions docs/branching-strategy.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion testnet-node/docker-compose.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down

0 comments on commit 47da8a8

Please sign in to comment.