Skip to content

[deps] fff.nvim at 0.9.6 (config targets 0.9.4); blink.cmp v2 imminent with breaking config changes #271

Description

@stanfish06

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.

Activity

  1. stanfish06 commented on Jul 27, 2026

    @stanfish06
    OwnerAuthor

    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, &amp; 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.


    Generated by Claude Code

  2. stanfish06 commented on Aug 10, 2026

    @stanfish06
    OwnerAuthor

    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") in lua/config/plugins.lua):

    1. Security-motivated dependency bump: git2 → 0.21.0 "to clear RUSTSEC-2026-0183/0184" (release notes).
    2. Default-behavior change: home-directory scanning now warns and is configurable rather than scanning silently — "warn when indexing $HOME", "make home-dir scanning configurable", "refuse fs-root/home index at Lua level before FFI" ([Suggestion]: Bump git2 to 0.21.0 to clear RUSTSEC-2026-0183/0184 for downstream consumers dmtrKovalenko/fff#733, #743, #745).

    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

  3. stanfish06 commented on Sep 28, 2026

    @stanfish06
    OwnerAuthor

    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.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions