Declare the modules through a shared version source, such as a Gradle platform or bill of materials where the vendor offers one, and group them in your update tool so one pull request moves them all. That keeps core and add on modules on versions the vendor tested together.
What is version skew?
Many SDKs ship as several modules: a core, plus pieces for login, payments, messaging or analytics. They are built and tested against each other at specific versions. If your build lets core move to a new release while an add on stays behind, you run a combination nobody tested. The symptoms are missing methods at runtime, class loading errors or changed behaviour that only appears in release builds.
Tool one: a platform or bill of materials
The Gradle documentation describes platforms as a way to ensure that all dependencies in a project use a coordinated set of versions, helping manage and enforce version consistency across modules, especially for sets of related dependencies. A bill of materials is a platform published for others to consume, and it can be built with the java-platform plugin and dependency constraints.
How it works in practice: you declare the platform once at one version, then declare the modules without versions. Upgrading is a single number. The vendor decides which module versions belong together.
Use it when the vendor publishes one. If they do not, you can write your own small platform for your own modules, but then you own the test matrix.
Tool two: grouped update pull requests
Dependabot's configuration has a groups option. The documentation says it defines rules to create sets of dependencies managed by a package manager, so updates arrive in fewer, targeted pull requests. Without groups, the default is one pull request per dependency.
A grouped pull request lets you review and test the whole SDK family as one change. Patterns on the package names are the usual way to define the group, for example everything from one vendor namespace.
A short setup plan
- List your SDKs that have more than one module in the project.
- For each, find out whether the vendor publishes a platform or bill of materials.
- Switch the declarations to use it, with modules unversioned.
- In the update tool, create a group per SDK family.
- Add a CI check that fails if two modules of one family resolve to different versions. A short script over the resolved dependency report is enough.
- Put the group's owner in the SDK register.
What grouping does not do
It does not decide whether an upgrade is safe. A grouped pull request is still an upgrade, so run it through the checks in our SDK upgrade pull request diff guide. It also does not cover other libraries that depend on one of your modules at a different version. For that, see why Gradle picks a newer version than you declared.
Try it yourself
Click through it at your own pace, or open it full screen.
Find the packages that come from the same vendor and check whether they sit on the same version.
Where Safeguard fits
Safeguard's dependency scanning and SBOM output list resolved versions per module, which makes skew inside one SDK family easy to spot. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a bill of materials the same as a lockfile?
No. A bill of materials declares which versions belong together. A lockfile records what actually resolved on a given build.
Does grouping updates make them safer?
It makes them easier to review as one unit. You still need to test the upgrade.
Sources
- Gradle documentation, Platforms: https://docs.gradle.org/current/userguide/platforms.html
- GitHub Docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
Last reviewed: 19 October 2026.
