diff options
author | Bundlerbot <bot@bundler.io> | 2019-09-12 07:54:24 +0000 |
---|---|---|
committer | Bundlerbot <bot@bundler.io> | 2019-09-12 07:54:24 +0000 |
commit | 9295e5df66bfc989bbc5a1c80e24f2233a8ad292 (patch) | |
tree | 993b2fa1869740ae814fcee5b954f40316b33284 /azure-pipelines.yml | |
parent | f7de5df5910d5bea9de22536b7f7f646fed30f6f (diff) | |
parent | 5057e5e55cfd8ecc20f124bda03650ff7a20f256 (diff) | |
download | bundler-9295e5df66bfc989bbc5a1c80e24f2233a8ad292.tar.gz |
Merge #7350
7350: Simplify `release:patch` task r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I'm using a slightly different workflow for releasing, but the current rake task does not work my way.
### What was your diagnosis of the problem?
My diagnosis was that previously the release task would push the changelog directly to the release branch and master. The way I'm doing it, I open a regular PR which can be reviewed and merged through bundlerbot just like any other PR.
### What is your fix for the problem, implemented in this PR?
My fix is to adapt the task to the workflow I'm using, and change it to only cherry-pick all the milestoned changes to the stable branch. I renamed it to `release:prepare_patch`.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows the release process itself to be reviewed, and it would allow us to protect the master and stable branches if we wanted to.
It also allows to make sure that CI is passing on the stable branch with all changes cherry-picked, before actually releasing. This could avoid, for example, bugs from being introduced from conflict-resolution errors while cherry-picking changes.
Co-authored-by: David RodrÃguez <deivid.rodriguez@riseup.net>
Diffstat (limited to 'azure-pipelines.yml')
0 files changed, 0 insertions, 0 deletions