-
Notifications
You must be signed in to change notification settings - Fork 8
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.
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
Ensure branches are merged up #32
Comments
Yep, and also it should set the new aliases. E.g. if we branched 3.5 from the 3 branch, it should KNOW to update the alias from |
I wonder if I should port the I guess having it done automatically on publish would be better? |
maybe something like
|
This is what I did for the last release, and most of it was manual and could be automated:
|
Note that cow/src/Steps/Release/RewriteReleaseBranches.php Lines 183 to 190 in 2c77958
|
(If it's a new major release, otherwise it should already be there)
👍 this is what was breaking Travis this morning
(If necessary) From a module perspective we've been doing the same thing (manually). Starting at the minor branch you're releasing a new patch tag on:
Continue the previous three steps until you reach the last minor branch, then:
Switch to next major+minor version branch (e.g. 4.0), then repeat the process. Continue until you run out of major version branches (e.g. 5), then switch master and merge the previous major version branch into it. Summary of composer alias requirements for branches (example module has branches master, 1.0, 1.1, 2, 2.0, 2.1, 2.2, 2.3, 2.4 for example):
Last thought: major version branches should be removed when the release line is no longer supported (e.g. the example above has had Bug fixes can still be released on the minor branch line. On that note, if no major branch exists in the release line when merging up then merge the last minor branch into the earliest minor branch in the next major release line, e.g. 1.1 gets merged into 2.0 instead of 1. |
One important question for this task is how it is run; Is it something that is run as a part of the release (during branching) or is it something run as a separate command after the release is complete. Perhaps it could be a part of both. |
It's a risky thing to merge up automatically between major versions I think - maybe the command could add If it's not part of the release process then it's likely to get forgotten about, but to be honest I think it's something that could be done by each module maintainer anyway. Personally - I wouldn't object to it being part of the release command as long as you can have a flag to stop it from being done if you want (global flag, not repo specific). |
The way it used to work is that it would automatically merge if possible, but on conflict it would pause and let the user modify these files. This is back in cow 1.0 with the old |
(My opinion) I'd feel safer if it always made you sanity check the changes, even if it could merge cleanly |
When doing a release
cow
should ensure branches are merged up and possibly assist in the merge up of branchesThe text was updated successfully, but these errors were encountered: