Ensure branches are merged up

[dhensby]

When doing a release cow should ensure branches are merged up and possibly assist in the merge up of branches

[tractorcow]

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 3.x-dev: 3.5.x-dev to 3.x-dev: 3.6.x-dev

[tractorcow]

I wonder if I should port the cow branch:merge tools up to 2.0... they were removed in 2.0 since they were broken but not immediately needed. The trouble is that we don't assume the same branches in all modules anymore, so I'm not sure how the CLI would work.

I guess having it done automatically on publish would be better?

[tractorcow]

maybe something like

cow branch:mergeup 3.5 framework : merges all versions 3.5 and later up:

• 3.5.1 -> 3.5
• 3.5 -> 3
• 3 -> master

[tractorcow]

This is what I did for the last release, and most of it was manual and could be automated:

• Branch 4 into 4.0 (automatically done by cow during release)
• On 4.0 branch:
  • Remove aliases (automatically done by cow)
• On 4 branch:
  • Merge 4.0 -> 4
  • Update aliases for 4.x-dev to 4.1.x-dev
  • Update requirements dependencies from to 4.1.x-dev (recipes only)
• on master branch
  • Merge 4 -> master
  • Update aliases for master to 5.x-dev
  • Remove aliases for 4.x-dev
  • Update requirements dependencies from to 5.0.x-dev (recipes only)

[tractorcow]

Note that Update requirements dependencies from to 4.1.x-dev (recipes only) has an implementation in cow, but it only does it on the release branch, not the parent semver branch (e.g. 4)

https://github.com/silverstripe/cow/blob/2c779581cd644a1c1346837a4d130ea818418fc7/src/Steps/Release/RewriteReleaseBranches.php#L183-L190

[robbieaverill]

Update aliases for master to 5.x-dev

(If it's a new major release, otherwise it should already be there)

Remove aliases for 4.x-dev

👍 this is what was breaking Travis this morning

Update requirements dependencies from to 5.0.x-dev (recipes only)

(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:

• Release the patch tag, push
• Move to next highest minor branch (e.g. change from 3.4 to 3.5)
• Merge previous branch (e.g. 3.4 into 3.5)
• Release new patch tag on current branch

Continue the previous three steps until you reach the last minor branch, then:

• Merge current minor branch (e.g. 3.8) into the major branch (e.g. 3)
• Branch current major branch (e.g. 3) to new minor branch (e.g. 3.9)
• Remove branch alias
• Merge back into major branch (e.g. 3)
• Update branch alias to the next unreleased minor version (e.g. 3.10.x-dev)

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):

• Minor branch, e.g. 2.4: no branch alias
• Major branch, e.g. 2: alias 2.x-dev to the next minor version without a branch e.g. 2.5.x-dev
• Master branch: alias dev-master to the next major version without a branch e.g. 3.x-dev

---

Last thought: major version branches should be removed when the release line is no longer supported (e.g. the example above has had 1 removed).

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.

[tractorcow]

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.

[robbieaverill]

It's a risky thing to merge up automatically between major versions I think - maybe the command could add --no-commit for those merges and let the user sanity check the changes before continuing?

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).

[tractorcow]

It's a risky thing to merge up automatically between major versions I think - maybe the command could add --no-commit for those merges and let the user sanity check the changes before continuing?

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 cow:merge command (did merging only, no branch alias rewriting).

[robbieaverill]

(My opinion) I'd feel safer if it always made you sanity check the changes, even if it could merge cleanly