[audit] vim.version.range("0.9.4") creates an open range ≥0.9.4, not a pin to exactly 0.9.4

[stanfish06]

What

plugins.lua:10 marks fff.nvim with:

version = vim.version.range("0.9.4"),

The comment on the same line says "this package breaks frequently, specify version", implying the intent is to pin fff.nvim at exactly 0.9.4. But vim.version.range("0.9.4") produces a range constraint meaning >= 0.9.4 with no upper bound — any later release also satisfies it.

Where

lua/config/plugins.lua:10

Why it matters

If vim.pack enforces version ranges during updates (behaviour may vary by nightly build), fff.nvim could be updated to a breaking release while the user believes it is pinned. The comment intent and the actual constraint are mismatched.

Recommended action

To constrain to the 0.9.x line only, use an explicit upper bound:

version = vim.version.range(">= 0.9.4, < 0.10"),

To pin to a single exact release, use a git SHA instead of a version range (vim.pack accepts a pin / commit-hash field depending on nightly API). Alternatively, accept that the constraint is a lower-bound floor and update the comment to reflect that.

Also worth verifying: whether vim.pack.add() actually reads and enforces the version field at all, since it is a nightly/experimental API. If it is ignored, the lazy = true field on the same entry may also be silently ignored (fff.nvim would then load at startup rather than on demand).

[stanfish06]

Premise disproven — recommend closing

This issue's core claim (vim.version.range("0.9.4") produces an open >= 0.9.4 range) does not hold, confirmed two independent ways:

1. PR [audit] fix: bound blink.cmp version range to stay off v2 #328 (2026-09-21) tested the equivalent blink.cmp case directly against nvim 0.13.0-dev-1661:

   vim.version.range("1.10.0")              from=1.10.0 to=1.10.0   has("2.0.0") = false
   

   A single-arg spec with all three version components (major.minor.patch) is an exact pin, not an open range — vim.version.range has no comma-compound parser, so >= 0.9.4 alone would actually behave differently (open), but a bare three-component string like "0.9.4" pins exactly.

2. nvim-pack-lock.json independently confirms this at the data level — both affected entries record the resolved range as an exact match, not an open one:

   "fff.nvim":  { "version": "0.9.4 - 0.9.4" }
   "blink.cmp": { "version": "1.10.0 - 1.10.0" }
   

   If the range were truly open-ended (>= 0.9.4), the lockfile would show no upper bound — it doesn't.

So plugins.lua:16's version = vim.version.range("0.9.4") already does what the adjacent comment says it does (pin exactly, to guard against the "breaks frequently" plugin). The secondary question this issue raised — whether vim.pack.add() enforces version at all — is also answered by the same lockfile evidence: it does, and used it to pick exactly 0.9.4.

Recommend closing as invalid. (Noting this now because a plugin-version sweep this cycle found fff.nvim upstream has since moved to v0.11.0 — see the update on #271 — and any future decision to bump the pin should account for it being a real exact-pin today, not an already-open range.)

---

Generated by Claude Code