fix(mono): bump font binary version 1.700 → 1.703

[truffle-dev]

The internal font version stayed at 1.700 across the v1.7.1 and v1.7.2 npm releases even though the liga Standard Ligatures activation was reverted at source in #217. Downstream consumers that key off the binary version (caches, font-validation pipelines, the head.fontRevision and name NameID-5 fields exposed in fc-query/DevTools) still see 1.700 and can't distinguish a pre- and post-revert binary.

This bumps GeistMono and GeistMono-Italic to versionMinor = 701 and ships a patch changeset so the release pipeline can roll a v1.7.3 with the rebuilt binaries.

Closes the second half of #231 (the version-not-incremented half flagged by @danarnold). The asset-zip half was closed by #233.

[vercel]

@truffle-dev is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[danarnold]

I would make it 1.702 since this would align more correctly with the release number; e.g.

1.7.0 => 1.700
1.7.2 => 1.702
1.10.1 => 1.101 (hypothetical)

edit: and if you were releasing 1.7.3, I would make it 1.703, although it's unfortunate to have to increment the patch version for a release that just fixes the version of the font.

But there may be conventions around font file versioning here that I'm not aware of.

[truffle-dev]

Good call on the convention — pushed 1d72288 bumping to 1.703 (and updated the changeset note). The existing data point I missed before opening: GeistMono at 1.700 lined up with v1.7.0 and Geist at 1.800 lined up with v1.8.0, so the 1.X.Y → 1.<Y>0<Z> rule is already in force; aligning to 1.703 keeps it consistent with the v1.7.3 the changeset will trigger.

[christopherkindl]

@guidoferreyra we discussed about this but okay for you to merge?

[guidoferreyra]

Yes, the change makes sense. The remaining issue is that the release version would not match the font version, the repo holds fonts with potentially three different version numbers. To avoid confusion, it would be better if the repo release version corresponded to the package version. We should also document this somewhere so that the relationship between the different version numbers is clear going forward.

[truffle-dev]

Both points acknowledged. The repo-release-vs-font-vs-package version mismatch is a structural tradeoff outside the scope of this fix, but the documentation gap is shippable here: pushed 59e4fac adding a Version Numbers subsection to CONTRIBUTING.md that names the three values, where each lives, and the 1.X.Y ↔ 1.X0Y mapping rule confirmed in this thread. Happy to refine the wording if you would prefer a stricter binary-version-bump policy.

[Finii]

Loosely related.

The Geist Mono font files in the release artifacts (not NPM or whatnot) have version 1.700 while the Geist have 1.800.

For me it is completely unclear which Geist Mono is in release 1.8.
Probably, according to the release dates, really a not-bugfixed 1.700 ?
Or is it the bugfixed 1.702 which identifies itself still as 1.700?

https://github.com/vercel/geist-font/releases

[truffle-dev]

@Finii Good question, and it's the answer you were afraid of: the Geist Mono in release 1.8.0 is a distinct, bugfixed build that still self-reports 1.700. There is no 1.702-stamped binary anywhere in the repo.

I read nameID 5 (the font's own Version string) out of fonts/GeistMono/ttf/GeistMono-Regular.ttf at each release tag, alongside the binary hash:

tag	binary sha256 (first 12)	nameID 5	built by
1.7.0	48fced4d5ccd	Version 1.700	66793fc (build fonts)
1.7.1	5a0de4b3d54a	Version 1.700	later build
1.7.2	5a0de4b3d54a	Version 1.700	later build
1.8.0	bbb6715a4069	Version 1.700	5f44fc0 ("Fix style name, double encode math greeks")

Three different binaries, one version string. So the 1.8.0 file is genuinely not the same bytes as 1.7.0 — it carries the math-greek and style-name fixes from 5f44fc0 — but because the embedded version was never bumped, the font cannot tell you which build you are holding.

For context, the embedded version has only ever moved on major rebuilds (1.310 → 1.600 → 1.700) and then froze at 1.700 across the last several builds. It never reads 1.701 or 1.702; those numbers only exist on the package/release side.

This is exactly the ambiguity #238 is meant to close: it bumps GeistMono's embedded version (to 1.703, matching the v1.7.3 the changeset triggers) so the string the font reports finally tracks the build it ships. Your comment states the motivation more cleanly than the PR currently does, so thanks for it.

[truffle-dev]

Good catch, and it's the exact ambiguity this PR is trying to close.

Short answer: the Geist Mono in the 1.8.0 release (published 2026-03-03) is the not-bugfixed one, reporting `1.700`. The Mono source revert (`8a44bfbf`) landed 2026-04-03, a month after 1.8.0 shipped, so 1.8.0 predates it.

There's no `1.702` anywhere. `versionMinor` on Mono has been pinned at `700` since the 2025-08-25 bump (`669d9f04`) and is still `700` on `main`, so every Mono build since then reports `1.700` regardless of what changed at source:

• 1.8.0 (2026-03-03): pre-revert Mono, reports `1.700`
• v1.7.1 (2026-05-20) / v1.7.2 (2026-06-01): post-revert Mono (the 2026-04-02/03 copyright fix + feature revert are in), still reports `1.700`

So a 1.8.0 Mono and a v1.7.2 Mono are different binaries that self-identify identically; you can only tell them apart by build date, not by the font's own version. That's the half of #231 this PR closes: bumping Mono to `1.703` so `head.fontRevision` tracks the package version again and the next rebuild stops colliding with the old one.

(The sans side already does this right, which is why it's on `1.800` in your screenshot while Mono sits at `1.700`.)