You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, we've had situations where a change was improperly backported or is missing from a branch and requires manual intervention.
@OVI3D0 brought up a good question on how to determine which branch a change should be backported to. There is information on this in CONTRIBUTING.md but it only details on how to backport but not when developers should. In order to know when a change should be applied to other branches, developers need to understand what kind of change they are proposing in the PR (i.e. is it focused on formatting, adding a new API, etc.). For example, a proposed API change might only be supported in newer versions like OS 1 and 2 but not ES 7 and thus the change should only be backported to OS 1 and 2 from main.
What solution would you like?
We should add more details to the contribution guide on what kinds of changes should be backported
Consider an automation that can be baked into the Pull Request and recommends users which labels this should have. This automation could leverage doing a git diff between branches' files.
This issue serves as an open discussion on what should be done to streamline the developer experience and reduce the amount of issues related to improper backports.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Previously, we've had situations where a change was improperly backported or is missing from a branch and requires manual intervention.
@OVI3D0 brought up a good question on how to determine which branch a change should be backported to. There is information on this in CONTRIBUTING.md but it only details on how to backport but not when developers should. In order to know when a change should be applied to other branches, developers need to understand what kind of change they are proposing in the PR (i.e. is it focused on formatting, adding a new API, etc.). For example, a proposed API change might only be supported in newer versions like OS 1 and 2 but not ES 7 and thus the change should only be backported to OS 1 and 2 from main.
What solution would you like?
This issue serves as an open discussion on what should be done to streamline the developer experience and reduce the amount of issues related to improper backports.
The text was updated successfully, but these errors were encountered: