1,035
edits
Upgrade Mastodon: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
** If it is not possible to preserve a hack, eg. because the relevant feature has been deprecated, update the corresponding feature page and include that in the pull request description | ** If it is not possible to preserve a hack, eg. because the relevant feature has been deprecated, update the corresponding feature page and include that in the pull request description | ||
** Don't try and fix failing tests here - that would edit the <code>glitch-soc-main</code> branch, which will then be overwritten on the next fork fix. | ** Don't try and fix failing tests here - that would edit the <code>glitch-soc-main</code> branch, which will then be overwritten on the next fork fix. | ||
* | * Merge <code>dev</code> into <code>merge-upstream</code> if necessary | ||
** It seems like this is the way [[glitch-soc]] does it, merge all from upstream masto into a branch from dev, then merge dev into the branch to ensure all glitch modifications go on top of the upstream? not exactly sure -jonny | |||
* Fix any failing tests in the <code>merge-upstream</code> branch | |||
** Ruby Tests, One and Two step db migrations must pass, but linting failing is fine and normal | |||
* If any changes were made after merging <code>dev</code>, [https://github.com/NeuromatchAcademy/mastodon/compare/dev...NeuromatchAcademy:mastodon:merge-upstream Create a pull request] from <code>merge-upstream</code> to <code>dev</code>. Otherwise just merge <code>merge-upstream</code> to <code>dev</code> | |||
** We do this additional step before merging to main because we might have collected some hacks or additional code in <code>dev</code> from some other branches before deploying (and generally we want to play the upstream over dev) | |||
* Merge <code>dev</code> to <code>main</code> | |||
== Discord == | == Discord == | ||