From 89e2d03cc8ce282b95594157dcbd1200338ef22e Mon Sep 17 00:00:00 2001 From: David Edey Date: Thu, 28 Nov 2024 14:56:08 +0000 Subject: [PATCH 1/2] Update `pull_request_template.md` --- .github/pull_request_template.md | 98 +++++++++++++------------------- 1 file changed, 41 insertions(+), 57 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index bfbd8b110e4..c81dd398e7c 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,62 +1,46 @@ -## Summary -``` -INSTRUCTIONS: -Add summary - one or two sentences explaining the purpose of this PR. -``` +> [!IMPORTANT] +> +> * Please read our [Contributing Guidelines](/CONTRIBUTING.md) before opening a PR. +> * Before creating your PR, please ensure you read the [node branching strategy](https://github.com/radixdlt/babylon-node/blob/main/docs/branching-strategy.md), which is also used in this repository. 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._ -## Details -``` -INSTRUCTIONS: -Provide further details about the changes, or how they fit into the roadmap. -You can delete this section if it's not useful. -``` +## Summary + ## Testing -``` -INSTRUCTIONS: -Further details about the tests you've added or manually performed. -You can delete this section if it's not useful. -``` + ## Update Recommendations -``` -INSTRUCTIONS: -This section is to provide recommendations to consumers of this repo about how they -should handle breaking changes, or integrate new features. The two key stakeholder -groups are dApp Developers and Internal Integrators, and there are separate sections -for each. - -In order to allow us to compile aggregated update instructions across PRs, please tag the PR -with 0+ of the relevant labels: -* scrypto-lib - Any change to the scrypto library -* sbor - Any breaking change to SBOR encoding/decoding -* manifest - Any change to manifest display, compilation/decompilation -* transaction - Any change which affects the compiled manifest, or transaction semantics -* substate - Any change to substates, the state model, or what's stored in the DB -* native-blueprint-interface - Any change to the interface of native blueprints -* files-moved - Any change to where engine types have moved, which will require - internal integrators to update their imports - -If you have a breaking change which doesn't fix into a category above, then tag it with -the closest label, and discuss in slack/discord. - -If your PR contains no breaking changes or new features or hasn't been tagged, this whole -section can be deleted. -``` - -### For dApp Developers -``` -INSTRUCTIONS: -Migration recommendations for a dApp developer to update their dApp/integrations -due to to the change/s in this PR. - -These will be aggregated by the Developer Ecosystem team and included in the next Scrypto migration guide -(eg https://docs-babylon.radixdlt.com/main/scrypto/release_notes/migrating_from_0.7_to_0.8.html ) -``` - -### For Internal Integrators -``` -INSTRUCTIONS: -Instructions to any internal integrations (eg Node, Toolkit, Gateway, Ledger App) for how the changes may affect -them and recommendations for how they should update to support this change. -``` + From 5192d2e93d051392884be71cc9867cd9809cf17a Mon Sep 17 00:00:00 2001 From: Azizi <64193693+azizi-a@users.noreply.github.com> Date: Tue, 3 Dec 2024 08:28:35 +0000 Subject: [PATCH 2/2] tweak: remove scrypto install script debug logging --- scrypto-install-scripts/install-scrypto-macos.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scrypto-install-scripts/install-scrypto-macos.sh b/scrypto-install-scripts/install-scrypto-macos.sh index 0ed66f6f904..e5d103c96de 100755 --- a/scrypto-install-scripts/install-scrypto-macos.sh +++ b/scrypto-install-scripts/install-scrypto-macos.sh @@ -1,7 +1,7 @@ #!/bin/bash -# Print commands and exit on errors -set -ex +# Exit on error +set -e # Versions to install LLVM_VERSION=18