Feature branches are a general term that means "not the main branch" (or master). Don't get too complicated with this. Create a branch just to upgrade that dependency. This should capture any additional code or documentation changes necessary during the upgrade. Breaking changes should be noted in the commit message. The commit message should include:
- Name of the dependency or library being updated
- Version of the dependency or library
- Notes about other code changes, especially breaking changes
- References to external work items if appropriate
For example, updating Selenium, which is used for automated testing, might have a commit message like this:
Upgrade Selenium NuGet package to v4.1.0
- Added DotNetSeleniumExtras package to support ExpectedConditions class
- Refactored page models to eliminate dependency on PageFactory
- Breaking changes to how screenshots are captured during failed tests
Whether you create a work item, story or task for this is up to you and your team. The key here is to communicate this change. Updates to dependencies can have large impacts when breaking changes are necessary, so coordinate with your team.
The smaller the change, the better. This makes updates easier to incorporate into existing work. Failing tests or bugs can be more easily tracked down to the upgrade if it can be encapsulated in a single branch, and a single commit.
Moving or renaming files as a result of the upgrade should be done in the same branch, but done as separate commits in order to preserve file history.
Work with your team on when to make this change, and to identify which branch the change gets merged into. Unless you have a compelling reason, I recommend merging it into your main branch, and making sure automated and manual tests are passing before merging it into other branches.