Goal
document the post-v2.1.0 changes for the v2.2.0 release.
Background and evidence
Release-preparation review of a90aa1429647b6eb4820a01aabe37799ca55ad5e on macOS arm64. Bash 5.3.20; ordinary local POSIX filesystem.
Current CHANGELOG [Unreleased] says No unreleased changes yet. despite 42 commits after v2.1.0, including user-visible fixes and release/security hardening. The release process instructs maintainers to move Unreleased entries into the next dated section, so following it now produces no useful v2.2.0 release notes.
Read-only evidence:
git rev-list --count v2.1.0..HEAD # 42 at the reviewed commit
git log --oneline v2.1.0..HEAD
Representative missing changes include staged vendor verification (#526/#528), named-output attributes (#509), standalone application payload boundaries (#510), SPDX semantic validation (#456/#519), timezone-independent archives (#511), repeatable positional defaults (#507), built-in route collisions (#506), completion cursor boundaries (#508/#527), and configuration/validator state isolation (#475-#479).
Closed #444 addressed the already-published 2.1.0 section. Open #530 addresses an orphaned documentation link. Neither covers these post-release notes.
Scope and acceptance criteria
- Audit the exact v2.1.0-to-candidate history and write categorized user-facing Unreleased notes with migration/compatibility implications where relevant.
- Include security fixes using safe public descriptions; distinguish already-published behavior from changes first shipped in 2.2.0.
- Keep the published 2.1.0 and earlier sections unchanged.
- Let the eventual release-prep PR own VERSION and the dated 2.2.0 transition; this issue may first populate Unreleased.
- Add a release checklist/review guard against publishing an empty placeholder for a release with notable changes.
Validation
Compare the release range against the completed issue/PR inventory, run documentation/release checks, and review the generated release notes without publication.
Source references:
Non-goals
No release publication or unrelated API redesign. Preserve documented compatibility except for the defective behavior identified above.
Project fields
- Project:
base-bash-libs
- Status:
Ready
- Priority:
P2
- Area:
Docs
- Initiative:
Adoption Polish
- Size:
M
- Milestone:
v2.2.0
Agent assignment
Assignee: @codeforester. Implementation may be handled through the normal issue-backed worktree and reviewed PR workflow.
Goal
document the post-v2.1.0 changes for the v2.2.0 release.
Background and evidence
Release-preparation review of
a90aa1429647b6eb4820a01aabe37799ca55ad5eon macOS arm64. Bash 5.3.20; ordinary local POSIX filesystem.Current CHANGELOG
[Unreleased]saysNo unreleased changes yet.despite 42 commits after v2.1.0, including user-visible fixes and release/security hardening. The release process instructs maintainers to move Unreleased entries into the next dated section, so following it now produces no useful v2.2.0 release notes.Read-only evidence:
git rev-list --count v2.1.0..HEAD # 42 at the reviewed commit git log --oneline v2.1.0..HEADRepresentative missing changes include staged vendor verification (#526/#528), named-output attributes (#509), standalone application payload boundaries (#510), SPDX semantic validation (#456/#519), timezone-independent archives (#511), repeatable positional defaults (#507), built-in route collisions (#506), completion cursor boundaries (#508/#527), and configuration/validator state isolation (#475-#479).
Closed #444 addressed the already-published 2.1.0 section. Open #530 addresses an orphaned documentation link. Neither covers these post-release notes.
Scope and acceptance criteria
Validation
Compare the release range against the completed issue/PR inventory, run documentation/release checks, and review the generated release notes without publication.
Source references:
Non-goals
No release publication or unrelated API redesign. Preserve documented compatibility except for the defective behavior identified above.
Project fields
base-bash-libsReadyP2DocsAdoption PolishMv2.2.0Agent assignment
Assignee: @codeforester. Implementation may be handled through the normal issue-backed worktree and reviewed PR workflow.