release: v2.8.0, and rewrite the npm description for what people search

[melihbirim]

Two things, both needing a publish to take effect.

npm description

Measured what npm's search actually indexes. The answer is name and description, nothing else:

field	indexed	evidence
name	strongest	exact name scores 1364; csvql query ranks #1
description	yes, as phrases	three current description phrases each rank #1 out of 1-2M results, scoring 306-363
keywords	no measurable effect	duckdb, simd, etl, dataframe, mcp are all keywords; absent from the top 25 for every one
README	not indexed	three real phrases from nodejs/README.md, all absent
downloads	weak	an 11/week package outranks us, and a 13k/week package scores 4x a 25M/week one

The old description owned phrases nobody types (no import no database, #1 of 2,097,569). The queries people do type are held by packages matching loosely at 104-167, while our exact-phrase matches score 306-363, so those slots were open by 2-3x.

Old:

SQL on CSV files in place — no import, no database. Zig/SIMD engine for Node and AI agents (MCP). Read-only by design.

New:

Run SQL on CSV files in place. Query large CSV files fast with no import and no database. A CSV SQL engine in Zig with SIMD parsing, for Node and AI agents (MCP). Read only by design.

Covers run sql on csv, query large csv files, csv sql engine and csv files fast while keeping the phrases already won. Every claim is one we have measured. Keywords left alone since they do nothing, and the README is left for humans since search never sees it.

This is a hypothesis from the scoring pattern, not a tested outcome: npm reindexes on publish, so it cannot be A/B tested beforehand. Baseline to compare against after release is in the table above.

The same text goes on pyproject.toml for consistency and clearer copy on the PyPI page, not as a measured SEO claim. PyPI blocks scripted search and publishes no field-weighting docs, so the npm result does not transfer.

v2.8.0

54 commits since v2.7.0. Highlights:

• feat LPAD/RPAD (feat: add LPAD/RPAD string functions #178), with truncation and NULL handling (fix: LPAD/RPAD truncate long values and leave NULL alone #179)
• fix SUM/AVG no longer change with --threads (fix: SUM/AVG no longer change with --threads (#185) #198)
• fix VARIANCE/STDDEV precision on large-magnitude values (fix: VARIANCE/STDDEV lose all precision on large-magnitude values (#190) #191)
• fix low-cardinality SELECT DISTINCT contending on shard locks (fix: low-cardinality SELECT DISTINCT contends on shard locks (#213) #215)
• fix stdin spool file surviving SIGKILL on macOS (stdin-aggregate spool file (macOS/Windows) not cleaned up if the process is killed or interrupted #177)
• perf prefix-XOR quote mask so quoted CSV skips like unquoted (perf: prefix-XOR quote mask so quoted CSV skips like unquoted CSV #212, perf: use the fused scan's record end at the remaining quoted call sites #218)
• perf high-cardinality GROUP BY (perf: high-cardinality GROUP BY builds each group once, not once per worker #184, perf: high-cardinality GROUP BY sorts a compact array and uses more merge shards #199), COUNT(DISTINCT) thread scaling (perf: COUNT(DISTINCT) scales with thread count instead of collapsing #180), fewer accumulator allocations (perf: SELECT DISTINCT stops allocating accumulators it never uses #182, perf: stop allocating unused aggregate slots for every group #183)
• Windows input files memory-mapped (Windows: memory-map input files; fix DuckDB-versions bench download #194)
• ci setup-zig retry (ci: retry the Zig install once when the download fails #220), docs-only matrix skip (ci: skip the build matrix for documentation-only changes #209)

release.yml derives npm and PyPI versions from the tag, but not src/main.zig, so that one is bumped here or csvql --version would keep reporting 2.7.0. pyproject.toml had also drifted to 2.6.0 and is now in line.

Verified locally: 657 tests pass, and bench/verify_correctness.sh is 103/103 against DuckDB.

🤖 Generated with Claude Code

[melihbirim]

Added a third change after finding it via the local release.sh helper, which bumps a version string this PR had missed.

src/mcp.zig line 31 hardcodes the MCP handshake response, including serverInfo.version. Tracing it:

ca82dab  chore: bump version to 1.0.1   <- last commit that moved it
407701c  chore: bump version to 1.0.0
afeabf0  Imprv/arena buffer (#37)

It has not moved since 1.0.1, so every release from 1.1.0 through 2.7.0 reported "version":"1.0.1" to MCP clients. Those releases were tagged directly rather than through release.sh, which is the only thing that bumps this field, and nothing else reads it so no test caught the drift.

Now 2.8.0, verified over the wire:

$ echo '{"jsonrpc":"2.0","id":1,"method":"initialize",...}' | csvql --mcp
serverInfo: {'name': 'csvql', 'version': '2.8.0'}
protocolVersion: 2024-11-05

protocolVersion is deliberately untouched: 2024-11-05 is the MCP spec revision, not our version, and the two sit on the same line.

Worth noting for later, not fixed here: this field will drift again the next time a tag is pushed without release.sh, since release.yml patches package.json and pyproject.toml from the tag but not either Zig source. Making the binary read its version from one place, or asserting it in a test, would close that off.

657 tests still pass.