release

NGINX UI Release

Use this workflow for NGINX UI releases from the repository root.

Preconditions

• Work from the dev branch.
• Inspect git status --short --branch before changing files.
• If the user asks to commit existing workspace changes first, inspect recent commit style and commit that work separately before release prep.
• Keep staging explicit. Do not include unrelated local changes.
• Treat release-notes-vX.Y.Z.md as a temporary local release artifact, not a committed file.

Version Preparation

1. Run ./version.sh outside the sandbox when possible. It updates app/package.json, runs the frontend build, and refreshes generated artifacts that can require network access.
2. Enter the release version as vX.Y.Z when prompted and confirm it.
3. Check the generated diff with git status --short and git diff --stat.
4. Commit only version-preparation artifacts with:

git add <version-prep-files>
git commit -m "chore: prepare vX.Y.Z"

Do not commit release-notes-vX.Y.Z.md.

Release Notes

Create release-notes-vX.Y.Z.md in the repository root using exactly these sections:

## Features

- <User-facing feature summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))

## Bug Fixes

- <User-facing fix summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))

## Contributors

@handle

Guidelines:

• Base the notes on the verified range from the previous release tag to HEAD.
• Every actual change bullet must include both the verified contributor's @handle and a linked short commit hash, even when a PR link is also included. The Contributors section does not replace per-change attribution.
• Resolve handles from the merged PR author and verified co-authors, or the GitHub-linked commit author for direct commits. Do not automatically credit the merger or committer, and never infer a handle from a display name or email. Resolve missing attribution before finalizing the notes; if it cannot be verified, ask the user for the handle or an explicit attribution exception.
• Use a commit that implements the summarized change and belongs to the verified release range. For squash merges, use the resulting squash commit; for rebased or cherry-picked changes, use the commit shipped in this repository. Never use the release-prep commit as a substitute.
• Display a unique abbreviated SHA, starting at 8 characters and extending it if ambiguous, and link it to the full commit SHA on GitHub.
• Write concise summaries of notable user-facing outcomes rather than copying the raw commit log. Group commits only when they describe one coherent change; retain all relevant contributor handles and the linked hashes needed to substantiate the summary. Split unrelated changes into separate bullets.
• List verified release contributors once each in Contributors, including everyone credited inline.
• If a change section is empty, use - None.; this sentinel needs no contributor or hash.
• Do not include test status unless the user explicitly asks for it.