docs/react-wiki-archive/Legacy-Branches.md
Note: This page is about contributing changes to legacy versions of the UI Fabric library, not using them in your app. If you're consuming Fabric/Fluent UI React, please use the latest version if possible!
(If you must use an old version, the process for consuming it is similar; just substitute the old version number when installing, e.g. npm install --save office-ui-fabric@6. Also, be sure to reference the correct version of the control documentation: here for version 6 or here for version 5.)
Fabric has separate branches with the code from previous major releases, such as 5.0 and 6.0. This page outlines the setup and development process for working in those branches.
We recommend using nvm (Node Version Manager) to manage and switch Node versions. The 5.0 and 6.0 branches require using Node 8 or 10 to build. (These steps are also useful if you're developing on master but need to use an older Node version in another repo.)
See the nvm setup page for instructions.
Due to the install structure differences and the significant number of changed files between major release branches (master, 6.0, and 5.0, etc), it's recommended to make a separate clone for each one.
To make a separate clone for development based off the 6.0 branch (as an example):
cd to an appropriate folder (such as the one above your main clone's root folder)fabric6)git clone https://github.com/microsoft/fluentui.git fabric6
cd fabric6
Git's worktree feature allows multiple working copies of a repo to share the same underlying Git store. Worktrees are powerful but a bit more complicated to set up and maintain, and not all tools handle them properly (VS Code and SourceTree do reasonably well). See this article on worktrees for more information on setup and pros/cons.
If you prefer to use the same clone for developing against multiple major release branches (and don't want to use worktrees), use the scrub script to clean up when switching between major releases. This script permanently removes all node_modules, build output, and other untracked files or uncommitted changes.
Commit or stash any changes you want to keep, then run yarn scrub (in master) or npm run scrub (in 6.0).
There are various ways to set up your own copy of the legacy release branch. One option is as follows (using 6.0 as an example):
git fetch upstream
git checkout upstream/6.0
git checkout -b 6.0
git push -u origin
With this approach, you can use the same commands as usual to update the branch or create additional branches off of it; just replace master with 6.0.
6.0 and 5.0 use different specific build commands than master, but otherwise the workflow is similar. Some special cases are covered below.
In this example, we'll cherry-pick a commit ce137b9 from master into 6.0.
As part of the cherry-pick process, ideally you should delete and re-generate the change files to ensure they point to the right commits.
git fetch upstream to ensure you have all the latest commitsce137b9 or ce137b9b03de9bb25ab6e2f86cf1786598122b9b)6.0 and ensure it's up to date:git checkout 6.0
git pull upstream 6.0
git push
git checkout -b cherry-pick-examplegit cherry-pick ce137b9 --no-commitgit commit to finish committingnpm run change to generate new change filesgit push -u origin to push the branchWhen making a pull request, be sure to select the old branch (such as 6.0) as the target! Otherwise your PR will show lots of modified files you didn't touch and lots of merge conflicts.