Release script should refuse to tag a version with no CHANGELOG section

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,058 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
bash
Ambito
release

Direzione di ricerca

Parti da tools/release/release-and-deploy.sh intorno alla riga 45, dove viene validato l'argomento obbligatorio notes-file, e guarda come viene analizzato il flag esistente --skip-regression in modo che --skip-changelog-check segua lo stesso stile. Conferma il formato esatto dell'intestazione usato in CHANGELOG.md (ad es. ## [8.1.4.01]) prima di scrivere il grep. È completato quando lo script esce con 2 e punta a docs/RELEASING.md passo 1 se la sezione o il file di note manca, passa altrimenti, e il escape hatch ripristina il vecchio comportement.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Two of the last four releases were tagged with no CHANGELOG section, and one of those also had a completely empty GitHub release body. Both were backfilled by hand afterwards. tools/release/release-and-deploy.sh already knows enough to have refused.

release CHANGELOG section at tag time release body at tag time
8.1.2.01 (2026-08-28) missing present
8.1.3.01 present present
8.1.4.01 (2026-09-02) missing empty
8.1.5.01 present present

docs/RELEASING.md step 1 is explicit that the docs land on master before tagging, "so the tag points at a self-describing tree". Nothing enforces it, so it depends on whoever cuts the release remembering — and twice in one week it was not remembered.

Why it is worth enforcing rather than remembering

The cost is not tidiness. A tag with no changelog entry means:

  • nobody can tell what shipped without reading a commit range;
  • the gap is invisible until someone writes the next entry and finds a hole above it;
  • backfilling is guesswork later — the 8.1.2.01 and 8.1.4.01 entries had to be reconstructed from diffs, and commit titles were misleading in both cases (8.1.4.01's read "expand max number of concurrent tasks", which undersold a watchdog stealing a simulation slot and a hard-coded test-site prefix reaching a production script).

Doing it at tag time costs one paragraph. Doing it a week later costs a diff review.

Suggested change

release-and-deploy.sh already takes the notes file as a required argument and fails if it is absent (:45). Two more checks in the same style, before the first gate:

  1. The CHANGELOG must have a section for the version being tagged.

    grep -q "^## \[${VERSION}\]" CHANGELOG.md || {
    echo "CHANGELOG.md has no '## [${VERSION}]' section." >&2
    echo "See docs/RELEASING.md step 1: land the release-cut docs on master before tagging." >&2
    exit 2
}

  2. The notes file must not be empty, so an empty release body cannot be published:

    [ -s "$NOTES" ] || { echo "notes file is empty: $NOTES" >&2; exit 2; }

Both are cheap, both fail before anything is tagged or pushed, and both point at the procedure rather than just refusing.

An escape hatch is worth having for the case where someone genuinely needs to tag without docs — --skip-changelog-check, matching the existing --skip-regression — so the guard is a speed bump rather than a wall.

Possibly also worth doing

The release title is set to the bare version (--title "$VERSION", :78), while the deploy skill documents X.Y.Z.BB (<short description>). Every recent release therefore has a bare version title. Either the script should take a short description or the documented convention should be dropped — right now the docs and the tool disagree, and the tool wins silently.

Context

Both backfills are on master: 8.1.2.01 and 8.1.4.01 in CHANGELOG.md, with 8.1.4.01's release body populated via gh release edit.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx

Lingua principale
Java
Stelle
140
Fork
35
Merge medio
22h 6m
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di virtualcell/vcell

Tutte le issue di virtualcell/vcell

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.