Skip to content
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.

Sign up for GitHub

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

Update release process #311

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from
Open

Update release process #311

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
47062ca
Update release process
matthewpwilson Jul 12, 2019
907f2fd
Fix typo
matthewpwilson Jul 12, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -135,10 +135,10 @@ We have three main branches in our repo:
### Release process

1. Ensure all code to be released is merged into `dev`.
2. Create a release branch locally based on `master`.
3. Merge commits to be relaased into the release branch. Avoid cherry-picking changes so that `master` always remains a subset of `dev`.
4. Update the version number in `package.json` according to [semantic versioning](https://semver.org/).
2. Make a PR into `dev` to update the version number in `package.json` according to [semantic versioning](https://semver.org/),
- Note: if the only changes being made are to the documentation, do not update the version number. In this case the GitHub Pages site will be published when `master` is built, but no new version of the plug-in will be published.
5. Make a PR to merge your release brnach into `master`. The reviewer should make sure all commits are suitable to release and version number has been updated appropriately.
3. Create a release branch locally based on `master`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think only the collaborators or admins should manage the release branches and the branch should appear on the main repo so that it can allow hot fixes or doc changes just before the release.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, why would you want to make any distinct changes in a release branch and not put them in dev first? They'll need to end up in dev eventually otherwise merging dev -> master will be a pain.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am confused with our way and the original gitflow's one. Reading about the gitflow again, it works little bit different from how we've been working. It says when a new release occurs the release branch is made based on dev, then all fixes(not new features) from that time until the release go to the release branch. Then finally the release branch is merged into both dev and master.
I guess this way, we don't have to track back which commits have to be merged into release branch. Also master still remains a subset of dev.

4. Merge commits to be released into the release branch. Avoid cherry-picking changes so that `master` always remains a subset of `dev`.
5. Make a PR to merge your release branch into `master`. The reviewer should make sure all commits are suitable to release and version number has been updated appropriately.
6. After the PR is merged, Jenkins will run a build of `master` and publish the new version to registry.npmjs.org.
7. Delete the release branch.