Files
renovate/lib/modules/versioning/same-major
Jamie Tanna 128f446e08 docs: ensure that config in documentation is error and warning free (#43727)
* docs: skip validation on JSON files that aren't Renovate config

As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.

Before we do that, we should opt-out JSON snippets that aren't anything
related to Renovate config.

* docs: don't validate invalid Renovate config

As it's intentionally referencing a manager that doesn't exist.

* docs: don't validate partial Renovate config

As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.

There are several code snippets we have that are part of a Renovate JSON,
but it doesn't make sense to convert these to a fully passing config, as
it'd reduce clarity on what we're trying to explain.

* docs: convert `baseBranchPatterns` snippets to code blocks

So we can validate them.

* docs: make sure that `datasourceTemplate` is set

So this passes validation.

* docs: clarify that `force` is global config

As it may not be clear, so we can make it extra clear with a `.js` file,
and note that it's global self-hosted config.

* docs: make sure `packageRules` is an array

* docs: `matchBaseBranches` needs `baseBranchPatterns` to be set

* docs: correct typo for `prBodyColumns`

* docs: mark global config snippets as such

As part of future changes, we'll use this to detect whether it's global
self-hosted configuration.

* docs: make sure `packageRules` wraps its children

* docs: add `allowedHeaders`

* docs: ignore deprecation warnings

As part of future changes, we'll use this to note that we don't care
about the validation warnings.

* docs: make sure `customManagers` wraps its children

* docs: make sure `fleet` wraps its children

* docs: validate JSON snippets are valid Renovate config

To make sure that we're always presenting valid JSON configuration to
our users, we can validate them as part of `check-fenced-code`.

As well as configuration errors we can warn for warnings, but allow code
blocks to opt-out, for instance when there's a known deprecation
affecting the code block.

We need to make sure to set `allowedEnv` for various code snippets that
reference environment variables.

* docs(development): document fenced code block checks

* docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`

As otherwise we see build failures i.e.

    WARNING -  Doc file 'modules/platform/gitlab/index.md' contains a link
       '../../../self-hosted-configuration.md#autodiscoverrepoorder', but the doc
       'self-hosted-configuration.md' does not contain an anchor '#autodiscoverrepoorder'.

This needs to be wrapped alongside all other options like `title`.

* fixup! docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
2026-06-02 13:29:48 +00:00
..

The 'Same Major' versioning is designed to handle the case where a version needs to treated as a "greater than or equal to" constraint. Specifically, the case where the version say, X.Y.Z signifies a range of compatibility from greater than or equal to X.Y.Z to less than X+1.

This process uses Semver-Coerced versioning beneath the surface, single versions (e.g., X.Y.Z) are converted to a range like X+1 and then passed to the corresponding semver-coerced method.

This method is handy when managing dependencies like dotnet-sdk's rollForward settings. Let's say a project uses dotnet-sdk version 3.1.0. It needs to be compatible with any version in the 3.x.x range but not with versions in the next major version, like 4.x.x.

For example:

{
  "sdk": {
    "version": "6.0.300",
    "rollForward": "major"
  }
}

The roll-forward policy to use when selecting an SDK version, either as a fallback when a specific SDK version is missing or as a directive to use a higher version. In this case with major it means that select the latest version with the same major. ie. >= 6.0.300 < 7.0.0

For such cases, the users would not want Renovate to create an update PR for any version within the range >= 6.0.300 < 7.0.0 as it would not change the behaviour on their end, since it is handled by the manager already.

Note: You should create a discussion before using this versioning as this is an experimental support and might have some edge cases unhandled.