Goose v3.27.2 Keeps Migration Release Notes Honest

pressly/goose is a Go database migration tool often found near batch jobs, warehouse loads, and service deploys that need schema changes to land in the right order. This week the activity is small, but it touches a part of migration work that operators notice quickly: release notes that match the actual changelog.

The recent Goose activity is compact. Two commits landed on June 30, with 13 insertions and 3 deletions across two files. That is not a feature wave, and it should not be read as one.

The useful signal is where the changes landed. One commit is the v3.27.2 release commit, and the other is the release note parsing fix. The touched files were CHANGELOG.md and scripts/release-notes.sh, which puts the whole window in release process territory.

For migration tooling, that still matters. Teams often upgrade Goose as part of a larger data platform base image, deploy template, or internal command wrapper. If the release notes lose their shape, the runtime may be fine, but the operator reading the upgrade has less context than the maintainer wrote down.

The shell change is small and specific. Before the fix, scripts/release-notes.sh stopped capturing a release section when it saw any Markdown heading that started with ##. That sounds reasonable until the changelog uses version headings at level two and detail headings below them.

In that layout, a subsection such as ### Added or ### Changed also starts with the same first two characters. The old condition could stop too early and drop the subsections from generated notes. The fix tightens the match so the capture ends only when the script reaches a version heading that starts with ## [.

# old
[[ "${LINE}" == "##"* ]]

# new
[[ "${LINE}" == "## ["* ]]

That is the kind of shell glob detail that looks minor in a diff and then shows up later as missing context in a release page. Goose uses Markdown structure to separate the meaning of changes. Losing that structure makes a release less useful for teams that scan for migration risk before changing a base image or command line wrapper.

Goose sits close to state. A migration tool may run before an API starts, before a batch job writes a new partition, or before a warehouse load expects a new column. The code path is small, but the blast radius of a bad assumption can be large.

That is why release notes need to preserve categories. A Fixed section tells an operator to look for reduced failure or cleaner behavior. A Changed section tells them to check defaults, flags, or generated SQL. A Removed section tells them to search scripts and wrappers before the upgrade.

The current activity does not show a Goose runtime change. There is no evidence here of a new dialect rule, new migration command, or changed SQL execution behavior. The point is more basic: the release artifact should carry the same structure as the source changelog, because people and bots use that structure to decide how much testing an upgrade needs.

The top changed files are also a useful boundary. CHANGELOG.md records the v3.27.2 release, while scripts/release-notes.sh controls how those notes are extracted. There is no broad refactor hidden in the file list.

That should guide the upgrade response. If Goose is baked into an internal image for ETL tasks, this looks like normal maintenance rather than a reason to rerun every historical migration. The better check is around automation that reads release notes, mirrors changelog entries into internal docs, or posts upgrade summaries into a deploy channel.

This is also a reminder for maintainers of similar tools. Changelog structure is part of the interface once scripts depend on it. Matching every line that starts with ## is simple, but it is not precise enough when the document also uses nested headings.

Treat Goose v3.27.2 as a small maintenance release unless your own upgrade process depends on generated release notes. The code activity points at documentation extraction and release packaging, not migration execution.

If you scrape Goose notes into internal systems, test the parser against ## [ version headings and ### subsections. The project just fixed this edge in its own script, which is a useful prompt to check local copies.

For teams that run Goose inside data job images, keep the upgrade path boring. Read the v3.27.2 notes, confirm no local wrapper expects the old flattened output, and move it through the same smoke test used for other migration tool maintenance.