mgr/dashboard: backporting guide
When a new PR brings features or syntax changes that won't work in the supported releases, and the PR is not planned to be backported, it should be required to document the nature of the breaking changes and how to adapt master code to each one of the previous releases.Examples of the kind of hints that might help backporters work:
- BS 4 to BS 3 (reverse) migration: list of corresponding classes:
invalid-feedback(master, octopus) replaced with
- Typescript (ECMAScript)/Angular: optional chaining operator
?.and null coalescing operator
??(Angular >9, master, Octopus), don't work in Nautilus, $localize to i18n, ...
- Python 3 to 2/Python 3.8 to 3.6:
- Updates on Angular, TS, Bootrstrap, SCSS, Python.
- Updates on dependent libraries.
- Changes on internal components, refactors and relocations of files or renames of components.
This should be a last 'mandatory' step for any PR with any of the above changes, UNLESS the PR itself is planned to be backported to ALL the supported releases.
Additionally, we could explore the possibility of additionally providing scripts/regular-expressions to ease backporting.