The new "create 3x PRs gha-update-js" workflow is wrong, now there are a bunch of PRs on 3x different branches, though there will be a lot of duplicated dep updates, particularly on the 6.0 + 6 branch equiv PRs.
Also silverstripe/admin is NOT being updated first. Its JS is a used in other modules, though I honestly don't know how much of it is "imported at runtime". If any code from there isn't, that means that the modules using code from admin will be using out of date code. To be safe, we should update the JS in the three silverstripe/admin before updating the JS in any of the other modules.
It seems like we should be doing something similar to silverstripe/tx-translator which runs an advanced script on a developers local, and creates PRs for a series of supported modules, one CMS version at a time, before going into peer review and merge, after which it's assigned back to the original developer for the next step
Assume that 5.4 is the old supported minor, 6.0 is the a newest supported minor, and 6 is the next-minor
I'm think we should stop doing the PR creation on a cron, and instead only have an automatically generated github issue with instructions. The updating of deps should happen on a users computer rather than on github actions
New workflow
Manually update silverstripe/admin JS deps first:
- update deps on 2.4, create PR if any changes, merge PR
- merge-up to 2
- merge-up to 3.0, resolve merge conflicts (basically undo all changes to package.json)
- update deps on 3.0, create PR if any changes, merge PR
- merge-up to 3
- update deps on 3, create PR if any changes, merge PR
Once that's done, simultaneously do the following for all supported modules:
- update deps on 5.4 equiv branches, create PRs, get merged
- merge-up to 5 equiv
- merge-up to 6.0 equiv, resolve merge conflicts e.g. undo package.json changes
- update deps on 6.0, creates PRs, get merged
- merge-up to 6
- update deps on 6, creates PRs, get merged
Acceptance criteria
The new "create 3x PRs gha-update-js" workflow is wrong, now there are a bunch of PRs on 3x different branches, though there will be a lot of duplicated dep updates, particularly on the 6.0 + 6 branch equiv PRs.
Also silverstripe/admin is NOT being updated first. Its JS is a used in other modules, though I honestly don't know how much of it is "imported at runtime". If any code from there isn't, that means that the modules using code from admin will be using out of date code. To be safe, we should update the JS in the three silverstripe/admin before updating the JS in any of the other modules.
It seems like we should be doing something similar to silverstripe/tx-translator which runs an advanced script on a developers local, and creates PRs for a series of supported modules, one CMS version at a time, before going into peer review and merge, after which it's assigned back to the original developer for the next step
Assume that 5.4 is the old supported minor, 6.0 is the a newest supported minor, and 6 is the next-minor
I'm think we should stop doing the PR creation on a cron, and instead only have an automatically generated github issue with instructions. The updating of deps should happen on a users computer rather than on github actions
New workflow
Manually update silverstripe/admin JS deps first:
Once that's done, simultaneously do the following for all supported modules:
Acceptance criteria