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

Add some detail to releasing steps #1190

Merged
merged 2 commits into from
Aug 24, 2018
Merged

Add some detail to releasing steps #1190

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
acf1acf
add note about pulling upstream changes to release branch
frangio Aug 10, 2018
53143be
add comment about upstream changes in merging section
frangio Aug 16, 2018
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
14 changes: 12 additions & 2 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ We release a new version of OpenZeppelin monthly. Release cycles are tracked in
Each release has at least one release candidate published first, intended for community review and any critical fixes that may come out of it. At the moment we leave 1 week between the first release candidate and the final release.

Before starting make sure to verify the following items.
* Your local `master` branch is in sync with your upstream remote.
* Your local `master` branch is in sync with your `upstream` remote (it may have another name depending on your setup).
* Your repo is clean, particularly with no untracked files in the contracts and tests directories. Verify with `git clean -n`.


Expand Down Expand Up @@ -44,8 +44,11 @@ Publish the release notes on GitHub and ask our community manager to announce th

## Creating the final release

Make sure to have the latest changes from `upstream` in your local release branch.

```
git checkout release-vX.Y.Z
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd add a git fetch upstream here, to emphasize the need to be up-to-date with upstream (in case no fetches occured since the release branch was created).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand, isn't this exactly what git pull is doing in the next line?

Copy link
Contributor

@nventuro nventuro Aug 12, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

If there is no local upstream/release-vX.Y.Z, the git checkout command will fail: a previous fetch prevents that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I still don't understand how this relates to my proposed steps.

Copy link
Contributor

Choose a reason for hiding this comment

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

The readme says:

Make sure to have the latest changes from upstream in your local release branch.

However, if the branch was created from a different computer, the one the final release is being made from may have not performed a fetch since then, and will therefore not know about the upstream/release-vX.Y.Z branch, making checkout fail. A previous explicit fetch prevents that.

This is, granted, a somewhat contrived scenario, and I'd expect the releaser to know enough of git to not need this help, but I'd still add it for completeness sake.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I prefer to leave the snippets simple even if somewhat incomplete, and later automate all of this in a script. Does that sound ok?

git pull upstream
```

Change the version string in `package.json`, `package-lock.json` and `ethpm.json` removing the "-rc.R" suffix. Commit these changes and tag the commit as `vX.Y.Z`.
Expand Down Expand Up @@ -75,7 +78,14 @@ npm dist-tag rm --otp $2FA_CODE openzeppelin-solidity next

## Merging the release branch

After the final release, the release branch should be merged back into `master`. This merge must not be squashed, because it would lose the tagged release commit, so it should be merged locally and pushed.
After the final release, the release branch should be merged back into `master`. This merge must not be squashed because it would lose the tagged release commit. Since the GitHub repo is set up to only allow squashed merges, the merge should be done locally and pushed.

Make sure to have the latest changes from `upstream` in your local release branch.

```
git checkout release-vX.Y.Z
git pull upstream
```

```
git checkout master
Expand Down