Update RELEASING and CONTRIBUTING (#828)

* update RELEASING * fix linting * update CONTRIBUTING * fix emphasis * add changelog to releasing.md * improve live testing guidelines * Update CONTRIBUTING.md Co-authored-by: Andrew Fleming <[email protected]> --------- Co-authored-by: Andrew Fleming <[email protected]>
OpenZeppelin · Nov 27, 2023 · d4a44ab · d4a44ab
1 parent 69befb3
commit d4a44ab
Show file tree

Hide file tree

Showing 4 changed files with 29 additions and 23 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -0,0 +1,8 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -37,15 +37,17 @@ As a contributor, you are expected to fork this repository, work on your own for
     git checkout -b fix/some-bug-short-description-#123
     ```
 
-3. Make your changes, add your files, update documentation ([see Documentation section](#documentation)), commit, and push to your fork.
+3. Make your changes, add your files, and [update the documentation](#documentation). Make sure to update the [CHANGELOG](CHANGELOG.md) (*[learn how](https://keepachangelog.com/en/1.1.0/)*).
+
+4. Commit and push to your fork.
 
     ```sh
     git add src/file.cairo
     git commit "Fix some bug short description #123"
     git push origin fix/some-bug-short-description-#123
     ```
 
-4. Run tests and linter. This can be done by running local continuous integration and make sure it passes.
+5. Run tests and linter. This can be done by running local continuous integration and make sure it passes.
 
     ```bash
     # run tests
@@ -55,12 +57,12 @@ As a contributor, you are expected to fork this repository, work on your own for
     scarb fmt --check
     ```
 
-5. Go to [OpenZeppelin/cairo-contracts](https://github.com/OpenZeppelin/cairo-contracts) in your web browser and issue a new pull request.
+6. Go to [OpenZeppelin/cairo-contracts](https://github.com/OpenZeppelin/cairo-contracts) in your web browser and issue a new pull request.
     Begin the body of the PR with "Fixes #123" or "Resolves #123" to link the PR to the issue that it is resolving.
     *IMPORTANT* Read the PR template very carefully and make sure to follow all the instructions. These instructions
     refer to some very important conditions that your PR must meet in order to be accepted, such as making sure that all PR checks pass.
 
-6. Maintainers will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of OpenZeppelin Contracts for Cairo.
+7. Maintainers will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of OpenZeppelin Contracts for Cairo.
 
     *IMPORTANT* Please pay attention to the maintainer's feedback, since it's a necessary step to keep up with the standards OpenZeppelin Contracts attains to.
 
@@ -86,7 +88,8 @@ If you want to run the documentation UI locally:
 
 Currently, Starknet's test suite has important differences with public networks. We strongly suggest testing new features against a testnet before submitting the PR, to make sure that everything works as expected in a real environment.
 
-We are looking into defining a better process for these integration tests, but for now the PR author/contributor must suggest an approach to test the feature when applicable, which has to be agreed and reproduced by the reviewer.
+We are looking into defining a better process for these integration tests, but in the meantime the PR author/contributor must test the feature in a live network and then share a link to a reviewable transaction.
+Ideally, the transaction should come from a verified contract whose execution can be traced, for the reviewer to evaluate and possibly reproduce.
 
 ## All set
 

diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md
@@ -17,4 +17,4 @@ Fixes #??? <!-- Fill in with issue number -->
 - [ ] Tests
 - [ ] Documentation
 - [ ] Added entry to CHANGELOG.md <!-- [learn how](https://keepachangelog.com/en/1.1.0/) -->
-- [ ] Tried the feature on a public network
+- [ ] Tried the feature on a public network <!-- Please share some tx link or proof to confirm proper behavior. -->
diff --git a/RELEASING.md b/RELEASING.md
@@ -1,34 +1,29 @@
 # Releasing
 
-Releasing checklist:
+(1) Checkout the branch to be released. This will usually be `main` except in the event of a hotfix. For hotfixes, checkout the release branch you want to fix.
 
-(1) Write a changelog.
-
-(2) Run version bump script with the new version as an argument and open a PR.
+(2) Create a new release branch.
 
 ```sh
-python scripts/update_version.py v0.5.1
+git checkout -b release-v0.8.0
 ```
 
-(3) Create and push a release branch.
-
-```txt
-git checkout -b release-v0.5.1
-git push release-v0.5.1
-```
+(3) Search and replace the current release version with the one to be released (e.g. `0.7.0` to `0.8.0`, or `0.8.0-beta.0` to `0.8.0-beta.1`).
 
-(4) Checkout the branch to be released. This should be `main` except in the event of a hotfix. For hotfixes, checkout the latest release branch.
+(4) Create the release entry in [the changelog](CHANGELOG.md) with the contents of the _Unreleased_ section, which should be left empty.
 
-(5) Create a tag for the release.
+(5) Push and open a PR targeting `main` to carefully review the release changes.
 
 ```sh
-git tag v0.5.1
+git push release-v0.8.0
 ```
 
-(6) Push the tag to the main repository, [triggering the CI and release process](https://github.com/OpenZeppelin/cairo-contracts/blob/b27101eb826fae73f49751fa384c2a0ff3377af2/.github/workflows/python-app.yml#L60).
+(6) Once merged, create a tag on the release branch and push it to the main repository.
 
 ```sh
-git push origin v0.5.1
+git tag v0.8.0
+git push origin v0.8.0
 ```
 
-(7) Finally, go to the repo's [releases page](https://github.com/OpenZeppelin/cairo-contracts/releases/) and [create a new one](https://github.com/OpenZeppelin/cairo-contracts/releases/new) with the new tag and the base branch as target (which should be `main` except in the event of a hotfix).
+(7) Finally, go to the repo's [releases page](https://github.com/OpenZeppelin/cairo-contracts/releases/) and [create a new one](https://github.com/OpenZeppelin/cairo-contracts/releases/new) with the new tag and the base branch as target (`main` except in the event of a hotfix).
+Make sure to write a detailed release description and a short changelog.