Release workflows

Release workflows

Three commands share one interface: git-extensions.sh, git-release-style.sh, and git-release-langpack.sh. They package local committed HEAD by default. Add --remote to use GitHub's default branch instead.

Goal	Example
ZIP from local HEAD	git-extensions.sh --create
ZIP from GitHub's default branch	git-release-style.sh --create --remote
Validate/package a remote language pack	git-release-langpack.sh --create --remote --check
Preview publication	git-extensions.sh --release --remote --dry-run
Publish to GitHub Releases	git-release-style.sh --release --remote
Replace an existing version intentionally	git-extensions.sh --release --remote --force

Run inside the package's repository, or use --remote --repo OWNER/REPO from elsewhere. Metadata and content come from the same pinned commit. Uncommitted and untracked content is excluded, and committed .gitattributes export-ignore rules apply. Packaging alone does not establish correctness or phpBB Customisation Database approval.

Shared options

Option	Meaning
-C, --create	Build a ZIP only.
-r, --release	Build a ZIP and publish it to GitHub Releases. Local publication requires clean tracked files and an already-pushed HEAD.
--remote	Pin and package GitHub's default-branch commit instead of local HEAD.
-n, --dry-run	With --release, build the ZIP and preview generated notes without changing a GitHub tag, release, or asset. A same-named local ZIP can be replaced.
-f, --force	With --release, permit replacement of an existing version's tag, notes, and ZIP. GitHub-enforced immutability and tag rules still apply.
-R, --repo OWNER/REPO	Select the repository for --remote; otherwise infer it from the current checkout. Rejected without --remote.
-o, --output DIR	ZIP destination, defaulting to ../git-exported relative to the repository root (or current directory when outside a checkout). Relative custom paths use that same root.
-h, --help	Show help.

Existing -g/--gh-release remains an alias for --release, and --output-dir remains an alias for --output. Language packs now use --release for GitHub publication too; use --create for a ZIP only. Invalid usage exits with status 2.

Publication workflow

1. Choose the intended source and version; run the project's relevant validation and tests.
2. Build with --create and inspect the archive.
3. For local publication, commit tracked changes and push HEAD first.
4. Preview with --release --dry-run (plus --remote if using GitHub's default branch).
5. Publish with --release when ready. Add --force only when replacing that existing version is intentional.

Remote mode preserves local branches and working files, including dirty or unpushed local changes. A preview still builds/replaces a local ZIP and contacts GitHub for checks/generated notes. Review the printed commit on each invocation: preview and publication may resolve different default-branch commits.

All three scripts print help with no arguments. Exit statuses are 0 success, 1 operational failure, and 2 invalid usage. See remote sources and migration and publication recovery.