Upgrading dependencies
Our general policy is to upgrade only patch versions of dependencies on maintenance branches. An exception to this is upgrading dependencies for the build, such as build plugins and the version of the build tool itself. The reason is that we want to keep the build consistent between branches to reduce the maintenance burden and avoid problems unique to a given branch. As long as we can produce equivalent artifacts, consumers of our artifacts should not be affected by upgrading even minor versions of build dependencies. Build dependencies are not passed onto users, so the upgrade in a maintenance branch should not affect our users.
Active development of the next feature release is done in the main branch. Here, we upgrade to the latest minor version of dependencies, so we can ensure compatibility with them and catch compatibility issues as soon as possible.
Dependabot opens pull requests for upgrading dependencies to each supported branch once per day. Make sure to add the pull request to the right milestone when merging.
However, you should merge pull requests for upgrades to the oldest supported maintenance branch first and merge that forward. If the minor version of a dependency has not changed between two branches, then the patch upgrade to the older branch will apply cleanly to the newer maintenance branch and eliminate the need for the duplicate pull request to it. If Dependabot does not automatically close the pull request, you can ask it to rebase after merging forward, and it should automatically close the pull request as not needed.
If, instead, the minor version is different between the branches, for example 1.3.5 on our 1.9.x branch and 1.4.2 on our 1.10.x branch, we may get a pull request upgrading to 1.3.6 to 1.9.x and upgrading to 1.4.3 to 1.10.x. When merging 1.9.x forward to 1.10.x there will be a merge conflict that needs to be resolved. Be careful to not overwrite the dependency's version on 1.10.x to the wrong version.