readme: update docs around doing releases

[tynes]

Description
Update the docs in the README for how to do releases. This information was already documented, just adding a bit more to prevent future problems.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 624f4b3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov-commenter]

Codecov Report

Merging #1985 (a47e9e8) into develop (a21cec6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1985   +/-   ##
========================================
  Coverage    74.42%   74.42%           
========================================
  Files           79       79           
  Lines         2545     2545           
  Branches       397      397           
========================================
  Hits          1894     1894           
  Misses         651      651           

Flag	Coverage Δ
batch-submitter	62.50% <ø> (ø)
contracts	90.48% <ø> (ø)
core-utils	57.50% <ø> (ø)
data-transport-layer	38.64% <ø> (ø)
message-relayer	70.86% <ø> (ø)
sdk	87.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a21cec6...a47e9e8. Read the comment docs.

[elenadimitrova]

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

[optimisticben]

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.

[elenadimitrova]

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

[optimisticben]

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

[tynes]

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)

[elenadimitrova]

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

[mslipper]

We generally need to rethink the changesets process. Until then, I'm approving this since it's better to at least have the bad process documented.