Skip to content

readme: update docs around doing releases #1985

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

Merged
mslipper merged 2 commits into from
Mar 3, 2022
+6 −0
Merged

readme: update docs around doing releases #1985

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a47e9e8
readme: update docs around doing releases
tynes Jan 5, 2022
624f4b3
Merge branch 'develop' into fix/release-readme
mslipper Mar 3, 2022
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
6 changes: 6 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,12 @@ Some exceptions to this rule exist for cases in which we absolutely must deploy
If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using the latest release candidate branch.
See below for info about release candidate branches.

### Release new versions

Developers can release new versions of the software by adding changesets to their pull requests using `yarn changeset`. Changesets will persist over time on the `develop` branch without triggering new version bumps to be proposed by the Changesets bot. Once changesets are merged into `master`, the bot will create a new pull request called "Version Packages" which bumps the versions of packages. The correct flow for triggering releases is to update the base branch of these pull requests onto `develop` and merge them, and then create a new pull request to merge `develop` into `master`. Then, the `release` workflow will trigger the actual publishing to `npm` and Docker hub.
Copy link
Contributor

@elenadimitrova elenadimitrova Jan 6, 2022

Choose a reason for hiding this comment

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

What happens if "Version Packages" PR gets merged to master? Won't that trigger the release properly as well? Don't quite get why merge to develop them master again

Copy link
Contributor

@optimisticben optimisticben Jan 6, 2022

Choose a reason for hiding this comment

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

Then master and develop would diverge.
Practically, the packages would be build from master fine (I tihnk), but the changeset files would not be removed from develop and the next dev -> master will try and add then again.

Copy link
Contributor

@elenadimitrova elenadimitrova Jan 6, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

But we can merge the same branch to master and also to develop and we'll have the same "Version Packages" commit in both, why all the complexities with PRs? Can't we just do

$ git checkout master
$ git merge --no-ff version-packages-branch
$ git checkout develop
$ git merge --no-ff version-packages-branch

Copy link
Contributor

@optimisticben optimisticben Jan 6, 2022

Choose a reason for hiding this comment

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

I don't have strong opinion on how the task is accomplished, only that the functionality and necessary steps are documented 😄

Copy link
Contributor Author

@tynes tynes Jan 7, 2022

Choose a reason for hiding this comment

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

I'm not super opinionated on how its done either as long as it works. The existing workflow is done via the github ui which is why it works the way it does. Doing it via git would mean that pushing to master is enabled and that the changesets workflow is setup to work on pushes and then we'd have to close the PR on github (unless its smart enough to auto detect merge on push)

Copy link
Contributor

@elenadimitrova elenadimitrova Jan 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

I suggest we reword this section

The correct flow for triggering releases is to update the base branch of these pull requests onto develop and merge them, and then create a new pull request to merge develop into master. Then, the release workflow will trigger the actual publishing to npm and Docker hub.

to

"The correct flow for triggering releases is to first merge the branch of these pull requests into develop via

$ git checkout develop
$ git merge --no-ff changeset-release/master

and then merge the PR to maser. Then, the release workflow will trigger the actual publishing to npm and Docker hub."
We don;t need to push to master this way but we can still avoid the convoluted PR mechanism cc @tynes


Be sure to not merge other pull requests into `develop` if partially through the release process. This can cause problems with Changesets doing releases and will require manual intervention to fix it.

### Release candidate branches

Branches marked `regenesis/X.X.X` are **release candidate branches**.
Expand Down