Feature Request: Support for "Floating" Minor Version Upgrades Without Specifying Patch Version

[guilhem-martin]

github demo repo

Tell us more.

Use Case: In my workflows, I often include GitLab templates using only the major and minor version numbers (e.g., 2.4), omitting the patch version. This approach ensures that the latest patch release within the specified minor version is always used automatically.

Desired Behavior: I would like to configure Renovate so that it can upgrade dependencies from one minor version to the next (for example, from 2.4 to 2.5), while still omitting the patch version. This way, after each upgrade, the included gitlab template is still pointing to the latest patch version, immediately.

Additional Context:

If I have a version pinned to a specific patch (e.g., 2.4.3), I want Renovate to continue updating to the next patch or minor version (e.g., 2.4.4 or 2.5.0), based on my existing configuration (such as separateMinorPatch). This is the current behavior, and I would like it to remain unchanged.

Summary:

• Support upgrading dependencies from one minor version to the next (e.g., 2.4 → 2.5), without specifying the patch version.
• Existing behavior for fully specified versions (major.minor.patch) would remain as is.

Thank you for considering this feature!

[github-actions[bot]]

Hi there,

Please help this Discussion progress by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

If you need help with running Renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[rarkins]

This is probably possible already. If you create a demo repo we can check.

[guilhem-martin]

With docker versioning applied to pom.xml / maven:

Renovate does not propose any upgrade. It's what I want to achieve for patch update (staying on 6.1 i.e. 2 digits version), but I would have wanted it to propose minor update (from 6.1 to 6.2).

[guilhem-martin]

Without docker versioning:

enovate proposes to migrate from 6.1 to 6.1.21 (for patch update) and from 6.1 to 6.2.8 (for minor update ; in both cases it adds a patch version, turning the 2 digits version into a 3 digits version.

"maven": [
{
"datasource": "maven",
"packageFile": "pom.xml",
"deps": [
{
"datasource": "maven",
"depName": "org.springframework:spring-core",
"currentValue": "6.1",
"fileReplacePosition": 228,
"registryUrls": ["https://repo.maven.apache.org/maven2"],
"depType": "compile",
"updates": [
{
"bucket": "patch",
"newVersion": "6.1.21",
"newValue": "6.1.21",
"releaseTimestamp": "2025-06-12T08:45:27.000Z",
"newVersionAgeInDays": 12,
"newMajor": 6,
"newMinor": 1,
"newPatch": 21,
"updateType": "patch",
"isBreaking": false,
"libYears": 1.5691675862506342,
"branchName": "renovate/org.springframework-spring-core-6.1.x"
},
{
"bucket": "minor",
"newVersion": "6.2.8",
"newValue": "6.2.8",
"releaseTimestamp": "2025-06-12T09:29:18.000Z",
"newVersionAgeInDays": 12,
"newMajor": 6,
"newMinor": 2,
"newPatch": 8,
"updateType": "minor",
"isBreaking": false,
"libYears": 1.5692510147133434,
"branchName": "renovate/org.springframework-spring-core-6.x"
}
],
"packageName": "org.springframework:spring-core",
"versioning": "maven",
"warnings": [],
"sourceUrl": "https://github.com/spring-projects/spring-framework",
"registryUrl": "https://repo.maven.apache.org/maven2",
"packageScope": "org.springframework",
"currentVersion": "6.1.0",
"currentVersionTimestamp": "2023-11-16T14:50:58.000Z",
"currentVersionAgeInDays": 585,
"isSingleVersion": true,
"fixedVersion": "6.1"
}
]
}
]

With docker versioning on:

Renovate does not propose any upgrade. It's what I want to achieve for patch update (staying on 6.1 i.e. 2 digits version), but I would have wanted it to propose minor update (from 6.1 to 6.2).

"maven": [
{
"datasource": "maven",
"packageFile": "pom.xml",
"deps": [
{
"datasource": "maven",
"depName": "org.springframework:spring-core",
"currentValue": "6.1",
"fileReplacePosition": 228,
"registryUrls": ["https://repo.maven.apache.org/maven2"],
"depType": "compile",
"updates": [],
"packageName": "org.springframework:spring-core",
"versioning": "docker",
"warnings": [],
"sourceUrl": "https://github.com/spring-projects/spring-framework",
"registryUrl": "https://repo.maven.apache.org/maven2",
"packageScope": "org.springframework",
"currentVersion": "6.1",
"fixedVersion": "6.1"
}
]

[rarkins]

Is 6.1 an actual version from the registry or is it a "constraint" meaning 6.1.*?

[guilhem-martin]

Ok, bull's eye: I ran mvn dependency:tree and indeed 6.1 is a constraint, its not an actual version (returns 404), so bad example from my side.

So I get back to the initial gitlab example:

include:
  - component: gitlab.com/to-be-continuous/terraform/gitlab-ci-terraform@5.6  # 5.6 version ; patch versions: 5.6.0 and 5.6.1. It also has 5.7 as a major version.
    inputs:
      image: dockerproxy.repos.tech.orange/hashicorp/terraform:latest
      review-enabled: true
      integ-enabled: true
      staging-enabled: true
      prod-enabled: false

for which I checked that 5.6 is an actual version. I setup "versioning": "docker" in renovate.json.

The result is:

"gitlabci": [
{
"packageFile": ".gitlab-ci.yml",
"deps": [
{
"datasource": "gitlab-tags",
"depName": "to-be-continuous/terraform",
"depType": "repository",
"currentValue": "5.6",
"registryUrls": ["https://gitlab.com/"],
"updates": [
{
"bucket": "minor",
"newVersion": "5.7",
"newValue": "5.7",
"releaseTimestamp": "2025-02-09T11:21:56.000Z",
"newVersionAgeInDays": 137,
"newMajor": 5,
"newMinor": 7,
"newPatch": null,
"updateType": "minor",
"isBreaking": false,
"libYears": 0.015591926686960933,
"branchName": "renovate/to-be-continuous-terraform-5.x"
},
{
"bucket": "major",
"newVersion": "6.2",
"newValue": "6.2",
"releaseTimestamp": "2025-06-20T08:18:50.000Z",
"newVersionAgeInDays": 6,
"newMajor": 6,
"newMinor": 2,
"newPatch": null,
"updateType": "major",
"isBreaking": true,
"libYears": 0.3741476725012684,
"branchName": "renovate/to-be-continuous-terraform-6.x"
}
],
"packageName": "to-be-continuous/terraform",
"versioning": "docker",
"warnings": [],
"sourceUrl": "https://gitlab.com/to-be-continuous/terraform",
"registryUrl": "https://gitlab.com/",
"mostRecentTimestamp": "2025-06-20T08:18:50.000Z",
"currentVersion": "5.6",
"currentVersionTimestamp": "2025-02-03T18:46:49.000Z",
"currentVersionAgeInDays": 142,
"isSingleVersion": true,
"fixedVersion": "5.6"
}
]
}
]

that is to say:

• no patch upgrade suggested: fine, we'll stay at 5.6 (implicitly benefitting from latest patch version)
• minor upgrade suggested to 5.7: fine, we upgrade while staying at two digits version
• major upgrade suggestion to 6.2: fine, we major upgrade while staying at two digits version

Note: to complete, another test below where I indicated this time a 3 digit version in the gitlab ci file, we can see it keeps the 3 digit version for the 3 proposed upgrades:

"gitlabci": [
{
"packageFile": ".gitlab-ci.yml",
"deps": [
{
"datasource": "gitlab-tags",
"depName": "to-be-continuous/terraform",
"depType": "repository",
"currentValue": "5.6.0",
"registryUrls": ["https://gitlab.com/"],
"updates": [
{
"bucket": "patch",
"newVersion": "5.6.1",
"newValue": "5.6.1",
"releaseTimestamp": "2025-02-03T18:46:49.000Z",
"newVersionAgeInDays": 142,
"newMajor": 5,
"newMinor": 6,
"newPatch": 1,
"updateType": "patch",
"isBreaking": false,
"libYears": 0.02017922374429224,
"branchName": "renovate/to-be-continuous-terraform-5.6.x"
},
{
"bucket": "minor",
"newVersion": "5.7.0",
"newValue": "5.7.0",
"releaseTimestamp": "2025-02-09T11:21:56.000Z",
"newVersionAgeInDays": 137,
"newMajor": 5,
"newMinor": 7,
"newPatch": 0,
"updateType": "minor",
"isBreaking": false,
"libYears": 0.035771150431253174,
"branchName": "renovate/to-be-continuous-terraform-5.x"
},
{
"bucket": "major",
"newVersion": "6.2.0",
"newValue": "6.2.0",
"releaseTimestamp": "2025-06-20T08:18:50.000Z",
"newVersionAgeInDays": 6,
"newMajor": 6,
"newMinor": 2,
"newPatch": 0,
"updateType": "major",
"isBreaking": true,
"libYears": 0.3943268962455606,
"branchName": "renovate/to-be-continuous-terraform-6.x"
}
],
"packageName": "to-be-continuous/terraform",
"versioning": "docker",
"warnings": [],
"sourceUrl": "https://gitlab.com/to-be-continuous/terraform",
"registryUrl": "https://gitlab.com/",
"mostRecentTimestamp": "2025-06-20T08:18:50.000Z",
"currentVersion": "5.6.0",
"currentVersionTimestamp": "2025-01-27T10:00:37.000Z",
"currentVersionAgeInDays": 150,
"isSingleVersion": true,
"fixedVersion": "5.6.0"
}
]
}
],

[guilhem-martin]

so thanks a lot for the support @rarkins
do you think it's valuable if I add some infos in the documentation about the way it works?

[github-actions[bot]]

Hi there,

Please locate the debug message packageFiles with updates in your logs and paste the contents here. Depending on your question, we may need the full list of packages or only one.

If you self-host Renovate: make sure you run Renovate with LOG_LEVEL=debug to get the debug log messages! Next, open the debug-level logs and search for packageFiles with updates. This text marks the start of a structured log message that shows every package file, dependency, and update that Renovate found.

Find the relevant dependency/dependencies in the log message, and copy/paste those parts into this discussion. If you do not know which bits we need, you can copy/paste the full log message.

Read the Renovate docs, Troubleshooting to learn more about getting the docs, and getting the correct type of logs.

Thanks, the Renovate team

[github-actions[bot]]

Hi, please format any copy/pasted code or logs so they're readable.

You can read a Markdown code formatting guide as well as some GitHub-specific information formatting code blocks.

Thanks, the Renovate team

[lkleeven]

I'd like to ask if this feature could be reconsidered. Yes, you can make it workable, but not really in a sustainable way.

Our context: For our company we offer GitLab CI components and we also offer the integration with Renovate by providing a GitLab CI component for it. Our GitLab CI components use semantic versioning and don't really impact anything in a way that teams would need to consciously update, so we rely on GitLab to resolve a version like @1 to use the latest 1.x.x version and to unburden the users from having to regularly look at the updates.

Now the described scenario will work, but only if we as GitLab CI component developers maintain the extra set of major and potentially also major.minor releases next the normal major.minor.patch releases. This is all extra unnecessary work, if we could only tell Renovate to keep using the same precision in the newValue as it does with currentValue. Or at the least make it possible in some way to influence the newValue in some way so we could save the work of the extra releases.

[guilhem-martin]

You may also configure your semantic release bot, let's take an example for a patch release, the bot may do for you:

• create a patch tag 1.2.5
• update the minor tag 1.2 to point to the latest patch tag
• update the major tag 1 to point to the latest minor tag

If this is of any help for your use case.

[lkleeven]

We already have our own release tool that we're now going to adjust to do these things for us. But as I tried to say, this still feels like a hack to work around a missing feature. GitLab CI components versioning and setting those versions has it's own quirks and it would be nice if there was a versioning scheme that deals with that.