Update release process #311
Conversation
matthewpwilson
force-pushed
the
mw-release-process
branch
from
90f1051 to
37a4833
Compare
Signed-off-by: matthewpwilson <[email protected]>
Signed-off-by: matthewpwilson <[email protected]>
matthewpwilson
force-pushed
the
mw-release-process
branch
from
37a4833 to
907f2fd
Compare
|
Not sure if tagging would help tracking the codes. Instead, we can leave the |
| - 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`. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| - 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`. |
There was a problem hiding this comment.
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.
I'm also wondering if we should be tagging the master branch with each release so we know exactly what code went in to a release. However we might be able to tell from the commit that updated package.json i.e. everything before that must be in the release.