You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[deps] fff.nvim at 0.9.6 (config targets 0.9.4); blink.cmp v2 imminent with breaking config changes #271
Two items not covered by the existing tracking issue #256.
1. fff.nvim: latest is 0.9.6, config range targets 0.9.4
Current config: version = vim.version.range("0.9.4") (see also #261 about this being an open range not a pin)
Latest release: v0.9.6 (June 21, 2026)
Breaking changes: None. v0.9.5 and v0.9.6 are patch releases with bug fixes and ABI-stable options structs. Safe to allow the newer versions.
Recommended action: Either accept the update (the open range >= 0.9.4 already allows it) or update the version string to ">= 0.9.6" to document the tested baseline.
2. blink.cmp v2 is in active development — pin to 1.x now
Current: blink.cmp v1.10.2 (the last planned 1.x release per maintainer notes — v1.10.0 was described as "final 1.x before 2.0")
What changed in v1.10.x: The frecency database location moved; the item.documentation.render field was removed; the BlinkCmpSourceCompletions autocmd was dropped. The current config uses keymap = { preset = "default" } and sources = { default = {...} } which are unaffected.
blink.cmp v2: In active development. The v2 API is a complete config restructure (new source registration model, renamed keymap preset keys, changed completion trigger configuration). The current config's blink.setup({...}) structure will break when v2 lands.
Recommended action:
-- In plugins.lua, pin blink.cmp to the 1.x line explicitly:
{
name="blink.cmp",
src="https://github.com/saghen/blink.cmp.git",
version=vim.version.range(">= 1.0, < 2.0"),
},
This prevents auto-update to v2 when it releases. Before migrating to v2, consult the blink.cmp v2 migration guide (will be published in the repo's CHANGELOG/wiki) and test the new config structure.
Urgency: High — v2 is described as landing "soon" and the maintainer has indicated 1.x will receive only critical fixes after v2 ships.
Update from a fresh pass on plugin versions (2026-07-27): blink.cmp's pinned rev (539053d8) is exactly the chore: bump version to 1.10.0 tag commit. Since then upstream has shipped v1.10.1 (hotfix for system-info field naming) and v1.10.2 (column alignment options, non-overlapping components, & cmdline trigger, vim.NIL/selection-race/buffer-state fixes) — 25 commits ahead, none breaking. The v1.10.0 release notes billed it as "the final 1.x release before 2.0," but as of today v2.0 still hasn't shipped — latest tag remains v1.10.2, three-plus months after that announcement. So the concrete, actionable gap right now is a trivial 1.10.0 → 1.10.2 patch bump with no breaking changes; the v2 migration this issue anticipates is still pending upstream.
Also spot-checked the other 21 plugins pinned in nvim-pack-lock.json against their upstream default branches — 20 of them are already pinned to exact current HEAD (the lockfile appears to have been refreshed 2026-07-26), so nothing else to flag this round.
Drift is now larger than the 0.9.6 noted above, and this release has two changes worth flagging beyond a routine bump (config still pins vim.version.range("0.9.4") in lua/config/plugins.lua):
Nightlies are already ahead at 0.10.4 as of 2026-08-09, so this plugin is moving quickly.
Recommended action: unpinning purely for the security fix is low-risk (it's a dependency-only change), but the home-dir scanning default change is config-relevant and should be reviewed before widening the version range — confirm the new default doesn't change behavior the config relies on (e.g. if fff.nvim is ever pointed at $HOME). Given that, this still reads as a judgment call rather than a mechanical pin bump, so no PR opened here — bundling with whatever range update comes out of this issue's blink.cmp/fff.nvim resolution seems right.
Update (2026-09-28 sweep): fff.nvim has moved further ahead
Since this issue's last note (v0.9.6, 2026-06-21), two more stable tags shipped:
v0.10.6 (2026-08-29)
v0.11.0 (2026-09-20)
The config's pin (plugins.lua:16, version = vim.version.range("0.9.4")) is now ~180 commits / 2 minor versions behind upstream. Note this pin is an exact pin, not an open floor — see the correction posted on #261, which had claimed otherwise; that claim doesn't hold; vim.pack is not auto-tracking these newer releases today, which is presumably intentional given the adjacent "breaks frequently" comment.
Given that same "breaks frequently" history, bumping straight to v0.11.0 isn't a safe mechanical PR — recommend testing v0.10.x and v0.11.0 for compatibility (including the native binary rebuild path in fff.download) before updating the pin, same caution as this issue already applies to the blink.cmp v2 question.
blink.cmp: no change since last note — still v1.10.2 latest stable tag (2026-04-04), no v2 tag yet, ~240 untagged commits on main toward v2. The version-range guard question raised here was tested and resolved in #328/#261: the current vim.version.range("1.10.0") is already an exact pin and already excludes v2, no code change needed.
noice.nvim / snacks.nvim (#327): re-checked, both unchanged — pinned revs still equal upstream HEAD, no new commits or tags on either.
Activity
stanfish06 commentedon Jul 27, 2026
Update from a fresh pass on plugin versions (2026-07-27): blink.cmp's pinned rev (
539053d8) is exactly thechore: bump version to 1.10.0tag commit. Since then upstream has shippedv1.10.1(hotfix for system-info field naming) andv1.10.2(column alignment options, non-overlapping components,&cmdline trigger, vim.NIL/selection-race/buffer-state fixes) — 25 commits ahead, none breaking. Thev1.10.0release notes billed it as "the final 1.x release before 2.0," but as of today v2.0 still hasn't shipped — latest tag remainsv1.10.2, three-plus months after that announcement. So the concrete, actionable gap right now is a trivial1.10.0 → 1.10.2patch bump with no breaking changes; the v2 migration this issue anticipates is still pending upstream.Also spot-checked the other 21 plugins pinned in
nvim-pack-lock.jsonagainst their upstream default branches — 20 of them are already pinned to exact current HEAD (the lockfile appears to have been refreshed 2026-07-26), so nothing else to flag this round.Generated by Claude Code
stanfish06 commentedon Aug 10, 2026
Update (2026-08-10): fff.nvim v0.10.3 — security fix + default-behavior change
Drift is now larger than the 0.9.6 noted above, and this release has two changes worth flagging beyond a routine bump (config still pins
vim.version.range("0.9.4")inlua/config/plugins.lua):git2→ 0.21.0 "to clear RUSTSEC-2026-0183/0184" (release notes).Nightlies are already ahead at 0.10.4 as of 2026-08-09, so this plugin is moving quickly.
Recommended action: unpinning purely for the security fix is low-risk (it's a dependency-only change), but the home-dir scanning default change is config-relevant and should be reviewed before widening the version range — confirm the new default doesn't change behavior the config relies on (e.g. if fff.nvim is ever pointed at
$HOME). Given that, this still reads as a judgment call rather than a mechanical pin bump, so no PR opened here — bundling with whatever range update comes out of this issue's blink.cmp/fff.nvim resolution seems right.Generated by Claude Code
Generated by Claude Code
stanfish06 commentedon Sep 28, 2026
Update (2026-09-28 sweep): fff.nvim has moved further ahead
Since this issue's last note (v0.9.6, 2026-06-21), two more stable tags shipped:
The config's pin (
plugins.lua:16,version = vim.version.range("0.9.4")) is now ~180 commits / 2 minor versions behind upstream. Note this pin is an exact pin, not an open floor — see the correction posted on #261, which had claimed otherwise; that claim doesn't hold;vim.packis not auto-tracking these newer releases today, which is presumably intentional given the adjacent "breaks frequently" comment.Given that same "breaks frequently" history, bumping straight to v0.11.0 isn't a safe mechanical PR — recommend testing v0.10.x and v0.11.0 for compatibility (including the native binary rebuild path in
fff.download) before updating the pin, same caution as this issue already applies to the blink.cmp v2 question.blink.cmp: no change since last note — still v1.10.2 latest stable tag (2026-04-04), no v2 tag yet, ~240 untagged commits on
maintoward v2. The version-range guard question raised here was tested and resolved in #328/#261: the currentvim.version.range("1.10.0")is already an exact pin and already excludes v2, no code change needed.noice.nvim / snacks.nvim (#327): re-checked, both unchanged — pinned revs still equal upstream HEAD, no new commits or tags on either.
Generated by Claude Code