* feat(versioning): Add `julia` versioning
Add a Julia versioning module that wraps npm/semver with the
small syntactic differences in Julia's `Project.toml` `[compat]`
specifier:
- Bare versions (`1.2.3`) are treated as caret ranges, per Julia's
default specifier rule.
- Comma is union (`1.2, 2` -> `[1.2.0, 3.0.0)`), not intersection
as in Cargo.
- `≥` is accepted as a synonym for `>=`.
Caret, tilde (incl. the leading-zero behaviour), equality,
inequality, and hyphen ranges all map directly onto npm's
semver, which the module delegates to. The corresponding section
of the Julia compatibility docs is the source of truth:
https://pkgdocs.julialang.org/v1/compatibility/
Modelled on the existing `cargo` versioning module, since Cargo
shares the bare-version-as-caret default; the comma/union
divergence is the only structural difference.
Tests are table-driven against every example in the Julia
docs (caret, tilde, equality, inequality, comma-union, hyphen
ranges with both zero-pad and wildcard semantics).
* refactor(versioning/julia): Drop unreachable ternary fallback
Replace the `newSemver ? npm2julia(newSemver) : null` ternary
with an early-return on falsy `newSemver`, bracketed by
`v8 ignore start/stop`. The previous `v8 ignore next` on the
ternary's null branch wasn't honoured by codecov, leaving the
PR with one uncovered branch. The early-return form makes the
defensive guard a single `if` v8 can ignore cleanly, brings
branch coverage to 100 %, and is more direct to read.
* fix(versioning/julia): Address review feedback
- `logger.info` -> `logger.warn` in the defensive `if (!newSemver)` block, so the message surfaces if it ever fires.
- `logger.warn` added to the `npm2julia` defensive empty-input branch.
- `isSingleVersion` converted to a function declaration.
- Dropped the unused `export` on `isValid`.
* Apply suggestions from code review
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* fix(versioning/julia): Use function declarations, and repair applied suggestions
- Remaining `const` lambdas converted to function declarations: `isVersion`, `matches`, and — same pattern, though not flagged individually — `isLessThanRange` and `isValid`.
- Added the `isNonEmptyString` import from `@sindresorhus/is` required by the applied `.filter(isNonEmptyString)` suggestions.
- Fixed `!.(` in `index.spec.ts`: the optional-call punctuation was kept after the non-null assertion, which is not valid TypeScript, so the spec no longer parsed.
- `getNewValue` is a required member of `VersioningApi`, so its assertion is dropped rather than converted (oxlint `no-unnecessary-type-assertion`).
- `urls` entry rewritten as a markdown link, which `versioning-metadata` now requires.
- String concatenations in `convertToCaret` rewritten as template literals (`prefer-template`).
* fix(versioning/julia): Count components per specifier
Precision was counted across the whole value, so replacing the union `0.10, 0.11` with `0.12.1` produced `0.12.0` instead of `0.12`. Both the `^`/`~` block and the caret reversal now count on the last specifier.
* refactor(versioning/julia): Name the specifier
Splitting the chain so the last-specifier step is visible at a glance.
* test(versioning/julia): Drop currentVersion column
No `getNewValue` result depends on `currentVersion`, so the column only widened the table.
* test(versioning/julia): Split tables by rule
The `matches` and `getNewValue` tables each covered several rules under one name, so a failure did not say which rule broke. They are now one block per rule, linked to the Pkg compatibility docs. Fills gaps along the way: `~0.0` and `~0`, the `v` prefix, non-version input to `isValid`, a union of pins against `isSingleVersion`, the null paths of `getSatisfyingVersion` and `minSatisfyingVersion`, prerelease to prerelease in `isBreaking`, and inequality entries under `bump` and `replace`.
* fix(versioning/julia): Bump the last specifier
`bump` on a union lost the bump: `"0.10, 0.11"` + 0.12.1 gave `"0.12"`, and `"1.2, 2"` + 2.5.0 gave `"2"`. npm bumps every comparator of a union and joins them with a space, which is not Julia syntax, and cutting the result to the current precision then dropped the new floor. `bump` now bumps the last specifier and keeps its full value: `"0.12.1"` and `"2.5.0"`.
* refactor(versioning/julia): Drop isVersion wrapper
It only forwarded to `npm.isVersion`, which the spread already provides.
* feat(versioning/julia): Add widen strategy
Julia's convention is to append to a compat entry rather than replace it. `widen` inserts the target as `major.minor` (`0.minor` and `0.0.patch` below 1.0), as dependabot's julia ecosystem does: in ascending position, keeping the entry's comma style, and leaving unchanged an entry that already admits the target or is a hyphen range.
* feat(versioning/julia): Keep bare majors bare
When an entry ends in a bare major such as `5`, `widen` writes `6` rather than `6.0`, keeping the entry's style. This also widens the floor: `"1, 2"` + 3.1.0 becomes `"1, 2, 3"`, which admits 3.0. CompatHelper writes bare majors throughout since JuliaRegistries/CompatHelper.jl@4c1b75412b ("Fix a bug where CompatHelper opens PRs to bump to e.g. "2.0" or "2.1", instead of just "2""); dependabot writes `major.minor`. Below 1.0 the `0.minor` form stays, since a bare `0` would admit every 0.x release.
* fix(versioning/julia): Keep exact pins exact
Appending to a whole-entry pin relaxes it: `"=6.1.0"` widened for 6.1.1 became `"=6.1.0, 6.1"`, which admits every 6.x from 6.1.0. `widen` now writes `"=6.1.1"`, as `bump` and `replace` already did. An entry that only contains a pin still gets the new specifier appended.
CompatHelper and dependabot both append today. The same complaint is JuliaRegistries/CompatHelper.jl#250 ("Don't make a PR to packages that use an equality specifier"), answered with an opt-out. dependabot/dependabot-core#15114 ("julia: bump exact pins to the new target instead of appending"), open and unmerged, proposes this fix after JuliaGPU/CUDA.jl#3152 ("Update CUDACore requirement from =6.1.0 to =6.1.0, 6.1").
* fix(versioning/julia): Write numeric compat values
Pkg's specifier grammar (`ver_regs` in Pkg.jl `src/Versions.jl`, unchanged from Julia 1.0 through 1.13) takes digits only, and its bounds compare major, minor and patch, so `1.6.10` admits both `1.6.10-rc1` and a JLL's `1.6.10+0`. `bump` and the exact-pin branch wrote such targets verbatim, which Pkg rejects; they now write `major.minor.patch`. dependabot does the same since dependabot/dependabot-core#16307 ("Keep JLL build metadata out of compat entries. A new entry is written as `major.minor.patch`: `Zlib_jll = "1.6.10+0"` is rejected by Pkg").
* fix(versioning/julia): Leave hyphen ranges alone
A whole-entry hyphen range is a manual constraint, so every strategy now leaves it unchanged, as dependabot does. `bump` wrote `"1.2.3 - 4.5"` + 5.0.0 as `"5.0.0 5.0.0"`, which Pkg rejects.
* fix(versioning/julia): Reject empty specifiers
Pkg rejects an empty specifier, whether it is the whole entry or one part of a union (`""`, `"1.2,"`). `isValid` accepted both, because the npm translation drops empty parts.
* feat(versioning/julia): Declare pin strategy
Lookup already pins through `getPinnedValue` and `isSingleVersion`, both implemented here.
* docs(versioning/julia): Describe compat updates
The readme covered how Pkg reads a `[compat]` entry but not how each range strategy rewrites one. It now gives an example per strategy, and the rules every strategy keeps: exact pins stay exact, hyphen ranges are left alone, and new values are `major.minor.patch`.
* fix(versioning/julia): Keep the operator on widen
The specifier `widen` adds now takes the last specifier's `~` or `^`: `"~1.2"` with 1.3.0 becomes `"~1.2, ~1.3"`, not `"~1.2, 1.3"`. A plain `1.3` is caret, `[1.3, 2.0)`, so next to `~1.2` it let in all of 1.x, wider than the entry asked for.
This departs from dependabot, whose spec "appends plain spec regardless of prefix": `"~0.34.6"` with 0.35.0 gives `"~0.34.6, 0.35"`.
* fix(versioning/julia): Make widen keep exact pins
`widen` now writes the new specifier as an exact pin when the last specifier is one: `"=1.2.3, =1.2.5"` with 1.3.0 becomes `"=1.2.3, =1.2.5, =1.3.0"`. It wrote a plain `1.3`, which Pkg reads as `[1.3.0, 2.0.0)` and which relaxed the pins, contrary to the readme's "an exact pin such as `"=6.1.0"` stays exact".
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* feat(versioning): Add `vcpkg` versioning
vcpkg per-port JSON declares one of four version schemes.
`version` is a relaxed dotted-number form like `3.1.4` or `1.2.3.4`, possibly with a prerelease tail.
`version-semver` is strict Semantic Versioning, like `3.1.4-rc.1`.
`version-date` is an ISO calendar date in `YYYY-MM-DD` form, optionally followed by dot-separated disambiguation identifiers like `2024-01-15.1.2`.
`version-string` is opaque text without a defined ordering.
The module detects the scheme heuristically from the input, with a strict calendar-date check that rejects malformed dates outright, and dispatches to the existing `semver` or `loose` versioning modules for ordered numeric comparison so the underlying schemes do not need to be reimplemented.
A vcpkg port can also carry a `port-version` integer for changes that do not alter the upstream source, written as `<base>#<port-version>` and omitted when zero.
The port-version acts as a tie-breaker after the base versions compare equal, so `1.2.3#1` is greater than `1.2.3#0`, while `1.2.4` is still greater than `1.2.3#1` because the base version wins.
Vcpkg has no range expression syntax. Manifest `dependencies` carry a single `version>=` lower bound, and `overrides` carry an exact pin. The `matches`, `getSatisfyingVersion`, and `minSatisfyingVersion` functions implement the `>=` constraint for the numeric and date schemes. Opaque strings have no ordering on the base, so a constraint over an opaque string is satisfied only by versions with the same base, with `port-version` still providing a `>=` comparison once the base matches.
`getNewValue` returns `newVersion` unchanged because vcpkg pins each dependency to a single exact version plus optional port-version.
Reference: https://learn.microsoft.com/vcpkg/users/versioning
* fix(versioning/vcpkg): Address review feedback
- Validate date heads with luxon.
- `compare` returns `null` for unorderable pairs, so `equals` is `compare(a, b) === 0`. `isGreaterThan('opaque#2', 'opaque#1')` is now true, matching `matches`.
- `isVersion` accepts any valid version, so a `version-string` port is no longer signalled as a range.
- Applied suggestions: non-null assertions for unreachable guards, getters narrowed to `string`, one sentence per line in the readme.
- Caught up with `main`: markdown-link `urls`, `isString` helper, redundant casts dropped.
* fix(versioning/vcpkg): Handle null coercion
`semver.coerce` returns null once a component exceeds 16 digits, which `numericRegex` accepts, so the non-null assertion threw for such versions - on a path Renovate takes for every release a datasource returns.
* fix(versioning/vcpkg): Compare values for equality
`matches` receives a bare version whatever its origin - a `version>=` lower bound, an `overrides` pin, or the `allowedVersions` config - so reading it as `>=` widened `allowedVersions` and made current-version detection resolve to the newest release instead of the current one.
`getSatisfyingVersion` and `minSatisfyingVersion` now follow `GenericVersioningApi`, which drops the accumulator loops.
* fix(versioning/vcpkg): Collapse validity predicates
`isValid`, `isVersion`, `isCompatible` and `isSingleVersion` all answered the same question once opaque strings became versions, so they now share one implementation. vcpkg has no ranges, and `isValid(input) && !isVersion(input)` is correspondingly never true.
* fix(versioning/vcpkg): Reject cross-scheme upgrades
vcpkg does not compare versions across schemes, so a candidate using a different scheme is not an upgrade of the current one. Renovate filters releases through `isCompatible` before sorting them, which keeps incomparable pairs out of the comparator.
* docs(versioning/vcpkg): Note why sorting falls back to 0
The fallback is safe because `isCompatible` keeps unorderable pairs out of the list being sorted, which is not visible at the return itself.
* fix(versioning/vcpkg): Follow vcpkg's dot grammar
vcpkg-tool parses a dot version's numbers and numeric prerelease identifiers as `0|[1-9][0-9]*` (`src/vcpkg/versions.cpp`), but the numeric scheme here accepted `\d+`. So `2024-01-15.01` and `01.2` counted as numeric and ordered against `1.2.3`. They are now opaque strings, which order only against themselves, as in vcpkg-tool's `compare_any` for text that is neither a date nor a dot version. `2024-1-1` stays a dot version (`2024` with prerelease `1-1`), which is how vcpkg-tool parses it.
* fix(versioning/vcpkg): Reject a stray #
vcpkg reserves `#` for the port-version: vcpkg-tool's `Version::parse` splits at the first `#` and rejects anything after it that is not a non-negative integer. `1.2.3#`, `1.2.3#abc` and `1.2#3#4` fell through to the opaque-string scheme and counted as valid; they are now invalid.
* refactor(versioning/vcpkg): Merge satisfying lookups
Without ranges, both lookups return the first version equal to the value, so `minSatisfyingVersion` now points at `getSatisfyingVersion`, as `isSingleVersion` and `isVersion` point at `isValid`.
* test(versioning/vcpkg): Drop non-string isValid test
The `null` and `undefined` rows already exercise the `isString` guard.
* docs(versioning/vcpkg): Spell vcpkg in lowercase
* docs(versioning/vcpkg): Note the inferred scheme
vcpkg takes a version's scheme from the field it is published under, but Renovate's versioning sees only the text, so it infers the scheme. The readme said the field decides; it now says the scheme is inferred, and where that differs from vcpkg: dotted text published under `version-string`, such as `tensorflow-cc`'s `2.3.1`, is ordered against `version` releases, which vcpkg refuses.
* docs(versioning/vcpkg): Fix sort-safety comment
Lookup's `filterVersions` keeps only releases that `isGreaterThan` the current version before anything is sorted, which drops every release that cannot be ordered against it; `isCompatible` runs after that, and not at all for unconstrained values. The comment in `sortVersions` credited `isCompatible`.
* feat(versioning): add a `gomod` versioning
First step of #44184: a versioning for Go modules that behaves like `semver`
for now and is not the default anywhere yet, so it can be tried on repositories
before the `go` datasource switches to it.
It exports `isPseudoVersion()`, which follows `IsPseudoVersion()` from
golang.org/x/mod/module and recognises all three pseudo-version forms, as the
place for Go version helpers that do not belong to the `go` directive's
`go-mod-directive` versioning.
* refactor(versioning/gomod): accept an undefined version in isPseudoVersion()
Review feedback on #46145: the callers check optional values such as
`upgrade.newValue`, so `isPseudoVersion()` takes `undefined` and answers
`false` for it, and they no longer need their own guard.
* refactor(versioning/gomod): return early for an undefined version in isPseudoVersion()
GitHub Actions' versioning somewhat mirrors the SemVer-style versioning,
but doesn't quite.
This is in the case that it's common to use (mutable) tags like `v7` or
`v4.2`, as well as full SemVer style` `v1.2.3` and `v1.3.4-rc2`, doesn't
quite match it.
In addition, with GitHub's recent move to introduce Immutable Tags,
these require new releases to be a full SemVer `major.minor.patch` tag.
However, we don't currently have a way to take users from `@v7` to
`@v8.1.1`, in the case they're using Immutable Tags.
Given this isn't currently straightforward with any of our existing
SemVer-y versioning modules like `semver-coerced` or `semver-partial`,
we should instead introduce a specific Versioning module.
This mostly covers the functionality that `semver-partial` has, but
needs to take advantage of the `allVersions` parameter to find the
"shortest" possible tag for a given resolved Semantic Version.
This was previously attempted in previous changes, but reverted in
db64cc6de0 due to additional complexity.
We won't turn it on by default right now, but as a future change.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(versioning): add elm versioning support
* fix(versioning/elm): remove unnecessary defensive check in nextMajor
* fix(versioning/elm): use named capture groups in range regex
* fix(versioning/elm): use semver gte instead of gt || eq
* Update lib/modules/versioning/elm/index.ts
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* feat(gitlab-ci): Add `semver-partial` versioning
* Add supported range strategies to semver-partial
* Add test cases for invalid semver inputs
* Remove unused sortVersions spec test
* Add tests for semver-partial versioning edge cases
* Simplify semver-partial version comparison logic
* Rewrite AI slop
* Add tests and improve semver-partial version matching
* Remove support for v-prefixed versions and bump strategy
* Refactor isLessThanRange to use parseVersion/Range
* Remove duplicate test cases in semver-partial spec
* Remove GitLab CI extract changes (split into separate PR)
* feat: add versioning for Hermit package manager
* Update lib/modules/versioning/hermit/index.ts
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
* Update lib/modules/versioning/hermit/index.ts
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
* Update index.ts index.spec.ts and readme.md according to PR comments
* fix: fix versioning test double negation and _parseVersion function which is just for testing
* fix: simplify hermit versioning implementation as suggested
* fix: use _compare to simplify versioning implementation
* fix: reword version in hermit versioning and make _isChannel & _getChannel static
* fix: remove duplicated title in test and make _config readonly
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* refactor(tools/distro-info): for later use in ubuntu and debian versioning
cr changes
* feat(versioning/debian): Debian codenames support
restore extracted code
* feat(versioning/debian): Debian codenames support
package.json, dropped the generate: prefix.
unit test mod as per CR
* feat(versioning/debian): Debian codenames support
now using the generic ver api interface
* feat(versioning/debian): Debian codenames support
revert exporting docker versioning
* feat(versioning/debian): Debian codenames support
switched to luxon for time handle
test fixes
dropped ts-ignore comments
* feat(versioning/debian): Debian codenames support
extract changes in distro.ts
* feat(versioning/debian): Debian codenames support
post merge changes
* feat(versioning/debian): Debian codenames support
cr changes
* feat(versioning/debian): Debian codenames support
- added support for pin range strategy
* feat(versioning/debian): Debian codenames support
- typos & metadata fixes
* feat(versioning/debian): Debian codenames support
- added isReleased to distro.ts
* feat(versioning/debian): Debian codenames support
- moved all time/date handling into distro.ts
- date freeze for ubuntu/debian/distro unit tests
* refactor(versioning/distro): Move date handling into distro.ts
- revert refactor #15272
* feat(versioning/debian): Debian codenames support
- merge distro refactor
* feat(versioning/debian): Debian codenames support
- extract private properties
* feat(versioning/debian): Debian codenames support
- cr changes
* feat(versioning/debian): Debian codenames support
- cr changes
* feat(versioning/debian): Debian codenames support
- cr changes
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Moves datasource, manager, platform and versioning code from lib/ into new lib/modules/
BREAKING CHANGE: External tools must update paths to datasource, manager, platform and versioning
Jesper Stemann Andersen