Git Submodules: Prioritizing Tagged Releases Over Latest Commits

[thavaahariharangit]

Summary

We're proposing a significant enhancement to how Dependabot handles gitsubmodule updates. Currently, Dependabot always bumps submodules to the latest commit on the tracked branch, regardless of release tags. PR #13052 introduces intelligent version detection that prioritizes semantically versioned tags over untagged commits.

The Problem

When using package-ecosystem: git_submodule, dependencies are currently always bumped to the latest commit on the branch specified in .gitmodule, even when only certain commits have release tags. This creates several issues:

1. Lack of Stability: Users are forced to track potentially unstable HEAD commits instead of stable releases
2. No Semantic Versioning: Updates lack semantic meaning (is this a breaking change or a patch?)
3. Inconsistent with Other Ecosystems: All other package managers in Dependabot prioritize tagged releases

This has been a long-standing pain point (see #1639, #2192).

The Solution

PR #13052 introduces semantic version awareness for git submodules:

• Tagged commits with valid semver (e.g., v1.2.3, 2.0.0) are now recognized as release versions
• These tagged releases take precedence over newer but untagged commits
• Untagged commits are still available but assigned pseudo-versions (0.0.0-N) that sort lower than tagged releases
• Backward compatible: Repositories without tags continue to work as before

How It Works

1. Fetches up to 250 commits from the tracked branch
2. Identifies commits with valid semver tags (with optional v prefix)
3. Creates release entries for each tagged commit with proper version ordering
4. Assigns pseudo-versions to untagged commits for ordering purposes
5. Update checker selects the highest version (prioritizing tagged releases)

Example Behavior

Consider a submodule with this commit history:

commit abc123 (tag: v2.1.0) - Latest tagged release
commit def456 - Unreleased commit
commit ghi789 - Unreleased commit
commit jkl012 (tag: v2.0.0) - Previous tagged release

Before: Dependabot would update to ghi789 (latest commit)
After: Dependabot will update to abc123 (latest tagged release v2.1.0)

Opt-Out Mechanism

Users who prefer tracking the latest commit (bleeding edge) can still do so by manually bumping past the latest tag. Once you're ahead of all tagged releases, Dependabot will continue tracking untagged commits.

Testing & Validation

The PR includes comprehensive test coverage:

• ✅ Multiple tags on the same commit
• ✅ Invalid/non-semver tags (properly ignored)
• ✅ Mixed tagged and untagged commits
• ✅ Backward compatibility (repos without tags)
• ✅ Version ordering correctness

Breaking Changes?

No breaking changes expected. This is an enhancement that makes the behavior more intelligent while maintaining backward compatibility. Repositories without tags will continue to work exactly as before.

Questions for the Community

• Is 250 commits a reasonable pagination limit for tag detection, or should we increase it?
• Should we add configuration options to explicitly opt-in/opt-out of tag prioritization?
• Should we support other tag formats beyond semver (e.g., date-based tags)?
• Are there edge cases we haven't considered?

Related Issues

• Closes #1639
• Closes #2192
• PR: #13052

We welcome your feedback before merging this change! Please share your thoughts, concerns, or suggestions below.

[ReenigneArcher]

I'm really looking forward to this change!

Is 250 commits a reasonable pagination limit for tag detection, or should we increase it?

I feel that many submodules might have than 250 commits between tags, though I don't have any evidence of that to be the case. For me the most commits on any submodule since a last tag is 201, which is from https://bitbucket.org/multicoreware/x265_git.git

Should we add configuration options to explicitly opt-in/opt-out of tag prioritization?

I think opt-out as the new behavior will be much preferred. Personally, I have to close dependabot PRs basically daily on many submodules after verifying that they are not a tagged release.

Should we support other tag formats beyond semver (e.g., date-based tags)?

.NET projects use 4 place versions, e.g. major.minor.patch.build ... not sure if anyone is using those as submodules though.

Are there edge cases we haven't considered?

Most likely.

It would be nice to ignore tags/releases marked as a pre-release in the GitHub API. I know this isn't part of git itself, so understand if that's out of scope.

[tooomm]

Should we support other tag formats beyond semver (e.g., date-based tags)?

I'm looking forward to using this at one point with VCPKG releases when integrating their repo as git submodule to avoid spamming updates.
VCPKG uses CalVer with YYYY.0M.0D, e.g. 2025.04.09.