Skip to content

docs: changelog and blog post for v0.10.0 - #4245

Draft
nicoloboschi wants to merge 2 commits into
mainfrom
docs-changelog-0.10.0
Draft

docs: changelog and blog post for v0.10.0#4245
nicoloboschi wants to merge 2 commits into
mainfrom
docs-changelog-0.10.0

Conversation

@nicoloboschi

@nicoloboschi nicoloboschi commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

Changelog entry and release blog post for v0.10.0, prepared ahead of the release — the tag does not exist yet and no release was triggered.

generate-changelog refuses to run without the tag, so v0.10.0 was created locally on origin/main, used to generate the entry, and deleted immediately. It was never pushed, so release.sh can still create it normally.

Contents

  • hindsight-docs/src/pages/changelog/index.md — generated 0.10.0 entry: 1 breaking change, 12 features, 7 improvements, 19 fixes, and one migration (e2f4a6c8b0d1, attachments + document_attachments — both new and empty, so it is quick on any deployment size).
  • hindsight-docs/blog/2026-09-09-version-0-10-0.md — hand-written release notes.
  • skills/hindsight-docs/references/ — changelog mirror, plus a pre-existing developer/extensions.md drift the skill regen picked up (the StaticKeys extension docs from feat(extensions): add StaticKeysTenantExtension — env-configured per-user API keys with per-schema isolation #3675 had not been mirrored).

What the blog post covers

Rebased onto origin/main after #4234 reverted free-threaded CPython 3.14 (#4037, #4067) — both are out of the changelog and the blog post.

The per-bank text-search switch and the webhook signature work are in the changelog but not the blog post.

Second commit: a generator fix

The first pass produced 37 entries for 221 core commits, against 65 for the 145-commit release before it — whole user-facing fixes went unlisted. Three causes, measured separately on that range:

change entries
baseline 37
max_completion_tokens 16000 → 100000 45
+ scoped grouping / "user-facing" rules 126
+ token-batched parallel summarization 152
  • max_completion_tokens was a shared budget on a reasoning model — reasoning bills against it, so a long commit list spends most of it before the first entry.
  • The prompt rules read as licence to merge unrelated fixes and to drop anything whose commit title sounds internal. Largest single effect.
  • One LLM call for the whole release. Commits are now batched by token count and summarized concurrently, then deduped. Holding model and prompt fixed, one call gives 120 entries against 152 for five batches: 40 commits get an entry only when batched, 8 only when not.

The input was never the constraint. A 245-commit release is ~8500 tokens of commit subjects in total, so every arrangement fits the context window many times over — a batch budget near the context window would be a single batch that changes nothing. The budget is 2000 tokens; what it bounds is how many commits the model weighs at once before it starts summarizing them away.

Default model is now gpt-5.6-terra. tests/test_generate_changelog_batching.py covers the batching arithmetic and the dedup guarantees with the LLM stubbed.

Before merging

  • main has moved on (fix(api): expose the bank template import request body #4247 landed after this branch was cut). The changelog is generated against the tag, so it will need a regenerate at release time whatever else happens — treat this entry as a draft of the shape, not the final list.

  • No hero image. Recent release posts carry /img/blog/version-X-Y-Z-release.png; this one still needs one.

  • openapi.json in the skill still reads 0.9.2 — correct today, but it needs a re-sync once release.sh bumps the version.

@nicoloboschi
nicoloboschi force-pushed the docs-changelog-0.10.0 branch 4 times, most recently from d5815df to bfd96ab Compare September 9, 2026 09:10
The 0.10.0 range (221 core commits) summarized to 37 entries, against 65 for the
145-commit release before it: whole user-facing fixes were unlisted.

Measured on that range, holding model and prompt fixed, one call over the whole
release produces 120 entries against 152 for five batches — 40 commits get an
entry only when batched, against 8 only when not. The input was never the
constraint: a 245-commit release is ~8500 tokens of commit subjects in total, so
every arrangement fits the context window many times over. What batching bounds
is how many commits the model weighs at once before it starts summarizing them
away.

* Commits are batched by token count and the batches summarized concurrently,
  followed by a dedup pass that merges the same change described twice across a
  batch boundary. The dedup result is re-ordered by the release's own commit
  order and filtered to commit_ids that were in the input, so a dropped or
  invented id cannot reorder the changelog or point a reader at a commit that
  isn't there.

* max_completion_tokens=16000 was a *shared* budget on a reasoning model —
  reasoning bills against it, so a long commit list spends most of it before the
  first entry is emitted. Worth 8 entries on its own (37 -> 45). Raised to 100000.

* The grouping rule read as licence to merge unrelated fixes that touch the same
  area, and "focus on user-facing changes" as licence to drop anything whose
  commit title sounds internal. Both are now scoped; this was the largest single
  effect (45 -> 126).

Default model is now gpt-5.6-terra.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant