-
Notifications
You must be signed in to change notification settings - Fork 431
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(docs): remove internal 'how to publish' from CONTRIBUTING.md
- Loading branch information
Showing
1 changed file
with
0 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,16 +27,13 @@ yarn dev | |
| - Rebase your feature branch regularly against `next`. Make sure its even with `next` before merging | ||
| - Once it's done, open a pull request targeting `next` | ||
| - After at least two reviewers has approved the pull request, you can merge it into `next` when you feel ready (if you're on the Sanity team, obviously) | ||
| - Everything except minor _trivial_ changes should go through pull-requests. If you're unsure whether it's a trivial change or not, submit a pull request just to be sure | ||
| - Pull requests should be as ready as possible for merge. Unless stated otherwise, it should be safe to assume that: | ||
|
|
||
| - The changes/feature are reviewed and tested by you | ||
| - You think it's production ready | ||
| - The code is linted and the test suite is passing | ||
|
|
||
| - It's fine to open a pull request to start a discussion / ask for help, but it should be stated clearly that it's not yet ready for merge. | ||
| - When the `next`-branch is thoroughly tested and ready to be released (either as a minor or major version bump), it should be merged into `current` and bumped. | ||
| - Critical fixes go straight into `current` (preferably through a pull request) | ||
|
|
||
| ## Merging | ||
|
|
||
|
|
@@ -47,14 +44,6 @@ Prefer squash + merge. If it makes sense to keep individual commits (e.g. differ | |
| - `current`: This contains all the features and fixes included in the latest official release. | ||
| - `next`: This includes everything scheduled for the next, upcoming release. | ||
|
|
||
| ## Publishing official releases | ||
|
|
||
| When `next` is ready for release, merge `next` into `current`, then run `yarn release` in the `current` branch and select version. After a successful release, remember to merge the new version number commits that were performed as part of the release into `next`. | ||
|
|
||
| ## Publishing _canary_ versions from feature branches | ||
|
|
||
| This can be done at any time by anyone and is done by `yarn release-canary`. This will publish with the commit hash from HEAD. | ||
|
|
||
| # How to file an issue | ||
|
|
||
| If you find a security vulnerability, do **NOT** open an issue. Email [email protected] instead. | ||
|
|
||