-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Update release docs and remove release script #175
base: dev
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,7 +7,7 @@ If you run into any problems feel free to create an issue. PRs are much apprecia | |
|
||
Join the conversation on [the Graph Discord](https://thegraph.com/discord). | ||
|
||
Please follow the [Code of Conduct](https://github.com/graphops/graphcast-sdk/blob/main/CODE_OF_CONDUCT.md) for all the communications and at events. Thank you! | ||
Please follow the [Code of Conduct](https://github.com/graphops/subgraph-radio/blob/dev/code_of_conduct.md) for all the communications and at events. Thank you! | ||
|
||
## Commit messages and pull requests | ||
|
||
|
@@ -46,48 +46,24 @@ Make sure to include an exclamation mark after the commit type and scope if ther | |
|
||
Commits in a pull request should be structured in such a way that each commit consists of a small logical step towards the overall goal of the pull request. Your pull request should make it as easy as possible for the reviewer to follow each change you are making. For example, it is a good idea to separate simple mechanical changes like renaming a method that touches many files from logic changes. Your pull request should not be structured into commits according to how you implemented your feature, often indicated by commit messages like 'Fix problem' or 'Cleanup'. Flex a bit, and make the world think that you implemented your feature perfectly, in small logical steps, in one sitting without ever having to touch up something you did earlier in the pull request. (In reality, that means you'll use `git rebase -i` a lot). | ||
|
||
Please do not merge main into your branch as you develop your pull request; instead, rebase your branch on top of the latest main if your pull request branch is long-lived. | ||
Please do not merge dev into your branch as you develop your pull request; instead, rebase your branch on top of the latest dev if your pull request branch is long-lived. | ||
|
||
We try to keep the hostory of the `main` and `dev` branch linear, and avoid merge commits. Once your pull request is approved, merge it following these steps: | ||
``` | ||
git checkout dev | ||
git pull dev | ||
git rebase dev my/branch | ||
git push --force-with-lease | ||
git checkout dev | ||
git merge my/branch | ||
git push | ||
``` | ||
|
||
Allegedly, clicking on the `Rebase and merge` button in the Github UI has | ||
the same effect. | ||
We try to keep the hostory of the `dev` branch linear, and avoid merge commits. Once your pull request is approved, merge using the `Rebase and merge` button in the Github UI. | ||
|
||
## Release process | ||
|
||
TL;DR | ||
|
||
``` | ||
1. Make sure both `dev` and `main` are up-to their respective head | ||
2. Checkout a release branch from `dev` branch | ||
1. update version in Cargo.toml | ||
2. run `scripts/release.sh` | ||
3. After script finishes, push the branch. Squash the commit if there were multiple attempts and commits. | ||
3. Open release PR, set merge target to `dev`. Do not delete the release branch. Rebase and merge. Make sure all tests pass. | ||
4. Repeat step 3 for `main`, delete release branch afterwards. | ||
5. Create Github release with target set to `main`. Generate release notes. | ||
1. Merge a release branch into `dev` branch which updates version in Cargo.toml and `CHANGELOG.md` | ||
2. tag the commit on the `dev` branch and push the tag (if tagged locally) | ||
``` | ||
|
||
We would like to keep `main` branch for official releases while using `dev` branch as the default upstream branch for features. Therefore ongoing development, feature work, and bug fixes will takes place on the dev branch, and only merge release tag commits to the `main` branch. | ||
|
||
To start working on a new feature or bug fix, contributors should create a new branch off of the dev branch. Once the feature or bug fix is complete, a pull request should be created to merge the changes into the dev branch. All changes to the dev branch should be reviewed by at least one other person before merging. | ||
|
||
When it's time to create a new release, we will merge the changes from the dev branch into the `main` branch using a pull request with new version tag (ex. `v0.1.0`). This pull request should be reviewed by at least one project owner before merging. Once the changes are merged into `main`, we will create a new tag for the release and use this tag to generate release notes and create a release in GitHub. To release a new version in crates.io, we update the version in Cargo.toml, utilize the tool [orhun/git-cliff](https://github.com/orhun/git-cliff) to maintain the changelog markdown by simply running the script under `scripts/release.sh` with the new version tag. | ||
|
||
git tag <X.X.X> | ||
git push --tags | ||
``` | ||
git tag -a vX.X.X -m "vX.X.X" | ||
Comment on lines
+61
to
-87
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are we intentionally changing doc to go from annotated tags to "regular"? (dropping the |
||
git push --follow-tags | ||
3. Create a release using the new tag from `dev` | ||
``` | ||
|
||
It's important to note that all changes to the `main` branch should go through pull requests and be reviewed by at least one project admin. This helps ensure that the `main` branch only contains clean releases and that any issues or bugs are caught before they are released to our users. | ||
To start working on a new feature or bug fix, contributors should create a new branch off of the dev branch. Once the feature or bug fix is complete, a pull request should be created to merge the changes into the dev branch. All changes to the dev branch should be reviewed by at least one other person before merging. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Think in some places here "should" really is a "need", and the original wording of project admin should be kept. One of the reasons for that is this is a public repo and this doc is meant to also serve external contributors: they can't merge on their own (or with only other external reviewers) |
||
|
||
By following this release process, we can keep our repository organized, ensure that our releases are clean and stable, and make it easier for contributors to work on new features and bug fixes. |
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.