Files
inkwell/packaging/release-notes.sh
T
bvandeusenandClaude Opus 5.5 f16224b07c
Android / Build, or is the channel already serving this? (push) Successful in 3s
CI & Build / Python lint (push) Successful in 2s
CI & Build / Build now, or wait for Android? (push) Successful in 2s
Desktop (Tauri) / Build, or is the channel already serving this? (push) Successful in 2s
CI & Build / Web typecheck and unit tests (push) Successful in 12s
CI & Build / Python tests (push) Successful in 23s
Android / Core and FFI clippy and tests (push) Successful in 51s
CI & Build / integration (push) Successful in 1m49s
CI & Build / Build & push image (push) Skipped
Desktop (Tauri) / Web tests, clippy, Rust tests and rustfmt (push) Successful in 2m20s
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 3m6s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 3m46s
Desktop (Tauri) / Update manifest (push) Successful in 3s
Android / Kotlin + Rust (APK) (push) Successful in 8m31s
Android / Build the server image (push) Successful in 1s
Root, CI, docs and packaging describe the project to a stranger (#6225)
#6225 "Comment standard sweep: root, config, CI workflows, docs and
packaging", milestone 546 "Bring the repo to the comment standard (rule 32)
and compose defaults (rule 198)".

- README restructured in newcomer order: what it is, quick start,
  configuration, setup pitfalls, updating and backups, features,
  troubleshooting, development, licence. Its quick-start compose carries
  no restart policy.
- Dockerfile and .env.example trimmed to one or two lines per setting.
- Workflows, packaging scripts and docs lose issue, run, note, rule and
  milestone references and their history narration. Comments that still
  described path filters and "step 6" as future work now state what the
  workflows do.
- ci-requirements.md rewritten against the current workflows. It said the
  build gated on typecheck and lint only, the integration lane did not
  gate, a v* tag published :latest, and ci-tauri lacked bsdtar and zstd;
  none of those is true now (the last checked against run 9630's log).
- Echo strings in guard-forward.sh and version.sh drop their note
  citations; every string a test asserts on is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 20:44:02 -04:00

79 lines
3.1 KiB
Bash
Executable File

#!/usr/bin/env sh
#
# The markdown body for a release: what went live since the previous one.
#
# release-notes.sh <tag>
#
# A release BUILDS NOTHING. The merge to `main` already published `:latest`,
# `:<sha>` and both channel feeds, and a tag rebuilding that same source would
# re-push `:<sha>`, which a published tag never allows.
#
# What a release is FOR is the changelog. There are two
# halves to "what am I running" and the version answers only the first —
#
# which build is this the footer, /api/config, the APK's versionName
# what is in it that was not ← this
# in the one I ran last month
#
# DERIVED FROM GIT, not hand-maintained. A CHANGELOG.md drifts into being
# aspirational — it records what someone meant to ship. `git log` records what
# shipped, and cannot say otherwise.
set -eu
cd "$(git rev-parse --show-toplevel)"
tag="${1:?usage: release-notes.sh <tag>}"
# The previous release tag, by DATE rather than by name.
#
# `v*` only: this repo also carries `dev` and `stable` tags, which are the fixed-tag
# pointer releases the updater reads. They move constantly and are not releases in
# this sense; sorting them in would make "the previous release" mean whichever
# channel published most recently.
#
# Excludes the tag being described, so re-running on an existing tag still produces
# the range that tag covers rather than an empty one.
prev="$(git tag -l 'v*' --sort=-creatordate | grep -vxF "$tag" | head -1 || true)"
if [ -n "$prev" ]; then
range="$prev..$tag"
header="Changes since \`$prev\`."
else
# The first release. Everything is new, and listing the entire history would be
# noise — say so instead.
range="$tag"
header="First release."
fi
printf 'Inkwell %s\n\n%s\n\n' "$tag" "$header"
# `--no-merges`: a merge commit's subject is "Merge branch ..." and says nothing
# about what shipped. The commits it brought in are listed individually, which is
# what somebody reading this wants.
#
# `%s` alone, not `%s (%h)`: the sha is in the forge's own view of the release and
# a reader chasing a specific change clicks through rather than copying a hash out
# of prose.
# CAPPED, because an unbounded list is not a changelog — it is a wall.
#
# The first dated release spans everything since `v0.1.0` — 181 commits at the
# time of writing: nobody reads that, and burying twelve interesting changes in it is worse
# than not writing one. Later releases will be short and the cap will never bite.
#
# The most RECENT are kept, not the oldest, and the count of what was dropped is
# stated — a truncated list that does not say it is truncated is a lie.
CAP=60
total="$(git log --no-merges --format='%s' "$range" | wc -l | tr -d ' ')"
git log --no-merges --reverse --format='- %s' "$range" | tail -"$CAP"
if [ "$total" -gt "$CAP" ]; then
printf '\n_...and %s earlier commits in this range, omitted for length._\n' \
"$((total - CAP))"
fi
printf '\n'
printf '%s\n' "_No artifacts here. Builds reach users from \`main\`: the desktop and Android"
printf '%s\n' "channels and the server image all publish on merge, with no tag required. This"
printf '%s\n' "release is a bookmark — it names a moment and says what was in it._"