Date-like versions `2024-01-03` are blocked by `maxMajorIncrement` default value

[RahulGautamSingh]

Discussed in #44324

^{Originally posted by GodVenn July 1, 2026}

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.220.0

Please tell us more about your question or problem

Hi!

I want to start off by saying that I really appreciate your product and the work you have put into making it so configurable and flexible - great work!

I am using the azure-bicep-resource datasource, but noticed that I never got any updates, nor any pending PRs.
Checking the debug logs revealed that the updates were silently getting dropped because bicep resources uses date-versioning, so it was hitting the maxMajorIncrement when attempting to update from one year to another.

Example:
Current version
resource keyvault 'Microsoft.KeyVault/vaults@2024-11-01'

Log message:
DEBUG: Skipping Microsoft.KeyVault/vaults@2025-05-01 because major increment 9400 exceeds maxMajorIncrement 500

I can fix this by changing the maxMajorIncrement, but IMO, the default for the bicep resource datasource should be set to a reasonable limit, disabled OR at least added as pending to visualize this to the users.

I think the suggestion in #42820 would be a good mitigation as well, as it could implicitly disable it for bicep modules by setting the maxMajorIncrementThreshold to 900 or something like that.

Logs (if relevant)

Logs

DEBUG: Skipping Microsoft.KeyVault/vaults@2025-05-01 because major increment 9400 exceeds maxMajorIncrement 500 (repository=...)

DEBUG: Skipping Microsoft.KeyVault/vaults@2026-02-01 because major increment 19100 exceeds maxMajorIncrement 500 (repository=...)

DEBUG: Skipping Microsoft.KeyVault/vaults@2026-03-01-preview because major increment 19200 exceeds maxMajorIncrement 500 (repository=...)

Possible Fix

Some users are suggesting to introduce a threshold approach, where we create a new confg field say maxMajorIncrementThreshold which could be used to detect if difference between 2 major versions is normal or not ie. in date-like versions it would cross 1000 between versions.

I am noy okay with the idea cause it's brittle and we might have to add different threshold of other non-semver version.

Instead I'd prefer to ignore apply maxMajorIncrement to versions which are not semver-like or do not have a meaningful major, minor separation.

Implementation is open for discussion.