microsoft
/
react-native-windows
зеркало из https://github.com/microsoft/react-native-windows.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
Страница: Backporting a Change
Страницы
API documentation About Backporting a Change Contributing to the CLI Creating new projects to test specific RNW versions E2E Test E2E Testing (Fabric) Forking upstream files with react‐native‐platform‐override Getting a JS callstack in the debugger Home How to promote a release Integration Process IntegrationTests Learning Resources Manual Validation Script Metro Guide Metro Troubleshooting Guide NativeAnimatedModule Release Guide Repository Contents Setup Triage Process Using the new architecture templates VS Code Debugging VS Code Direct Debugging VS Remote Debugging Versioning and Release Process flow check
3 Backporting a Change
Tatiana Kapos редактировал(а) эту страницу 2024-11-08 14:08:18 -08:00
Содержание

Here is the set of documentation on how to backport a change into a 0.XX-stable branch.

Steps:

  1. Get an up to date copy of the 0.XX-stable branch you wish to backport to:
    1. If you don't already have a 0.XX-stable branch in your fork of react-native-windows, run git fetch --recurse-submodules upstream && git checkout 0.XX-stable && git merge upstream/0.XX-stable && git push.
    2. If you already have a 0.XX-stable branch in your fork of react-native-windows, checkout the branch and rebase by running git pull upstream 0.XX-stable --rebase.
  2. From your 0.XX-stable branch, checkout a fresh branch which will the branch that holds your backport changes: git checkout -b backport<commit>
  3. You have a few options on how to get the changes you wish to backport into your new branch:
    1. If the change is small, you can simply go in and manually make the edits.
    2. If the change is larger, run git cherry-pick <commit>.
      1. Note, if you choose this option, it's always safest to delete the change file and rerun yarn change at the root of the repo, in case the change type options are different on the 0.XX-stable branch you want to backport to (i.e. if the 0.XX-stable branch is no longer in preview, the types will change and not adjusting the change file type will break the publish pipeline).
  4. If a PR you picked has changes in yarn.lock, you may want to rerun "yarn" from the root of the repo to get the correct yarn.lock
  5. Now, commit and push your changes (make sure to push to your fork, not upstream): git push -u origin.
  6. Create a PR:
    1. Make sure you have selected 0.XX-stable as the branch you want to compare your changes against (it will default to main).
    2. Make sure your PR title matches the title of the original PR with [0.XX] added as a prefix.
    3. In your PR description, add the line "Backporting # into 0.XX".
    4. Copy the PR description from the original PR into the current PR description.

FAQ

Q: Which branches will accept backports?

Typically, we will accept backports up to the n-1 branch, where n is the version marked latest.

Q: What kinds of changes will be accepted for backporting?

The answer to this depends on the branch you are attempting to backport to. If the branch is in preview (i.e. it is the most recent 0.XX-stable branch that has only been release in preview, but not as 0.XX.0 yet), most changes are fair game, with the caveat that they must be thoroughly tested; we don't want to break a stable branch.

If the branch has already been released (i.e. it's version structure matches 0.XX.0), we will not accept changes to the app/module templates. This is because we don't want developers who are making minor version updates to see changes to their app/module templates. This source should stay consistent across a particular 0.XX.

In general, smaller scope changes are more likely to be taken than larger changes, as they hold less risk for breaking the platform.

In general, it is always good to ask yourself "Is this change needed in 0.XX, or can it be pushed to the next version of RNW?", "What users are on 0.XX that need this change?"