Ceph » mgr » Dashboard

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 help-block (nautilus), ...
• 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:

Instead of putting this burden on the shoulders of backporters, which will have to deal with chunk of code they aren not always familiar with, this should be proactively updated when breaking changes are introduced in master:

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