AlpineClubBookingsNZ v0.11.0
Release target: v0.11.0 on 2026-07-13. This minor public reference release
brings all changes landed after v0.10.1 into one supported tag. The canonical
detailed entries remain in CHANGELOG.md; this page is the release/operator
overview.
Highlights
- First-class multi-lodge scoping across bookings, capacity, rooms/beds,
seasons/rates, instructions, member access, requests, waitlist, roster, kiosk,
hut leaders, lockers, promos, work parties, and operational reporting. - Portable Configuration Export & Import with dry-run, explicit matching,
category selection, merge/overwrite modes, bundle integrity warnings, and an
automatic pre-apply backup attempt when backups are enabled. Operators must
independently ensure a current, restore-tested database backup exists before
applying an import; Configuration Export is not a database backup. - Declared partner relationships, admin partner management, partner invitation
claim/cancellation, shareable-double placement, and capacity headroom bounded
by both double-bed inventory and the lodge sleeping ceiling. - Admin recovery workflows for retroactive bookings, date overrides, explicit
over-capacity admission, capacity holds, finished-stay restrictions, and
per-action member-notification choices. - Safer bed allocation for large/minor groups, whole-stay moves, draft
preservation, room continuity, clearer booking identity, and conflict
feedback. - Finance and credit hardening for Internet Banking credit-note allocation,
cancellation/refund restoration deduplication, Xero lock-date enforcement,
and scoped reconciliation. - Editable access-role definitions, permission-aware setup navigation,
committee contact routing, membership-type retirement/merge, and improved
admin queue/filter/pagination visibility. - Restrained Alpine design system across public utility, member, and admin
surfaces: editable brand tokens, semantic accessible states, responsive
tables/forms, consistent alerts/status/occupancy, reduced motion, skip links,
dark mode, and stronger empty/loading/filter/calendar patterns. - Eleven additional operational email templates are admin-editable while
remaining always-send; admin-initiated member email suppression is explicit
and audited where suppression is safe. - CI now treats the multi-lodge E2E suite and static/dead-code analysis as
blocking release safeguards.
Compatibility and operator impact
- Runtime requirements remain Node.js 24 LTS, npm 11+, and PostgreSQL 16.
- The release contains 30 migrations. Twenty-six have explicit safety-ledger
rows because they touch hot tables, contain contract/data operations, or need
a documented deployment plan. The four without rows were checked directly
against the validator and ledger policy and do not require rows:20260707115737_committee_contact_email_modeadds a new enum plus two
columns to the cold, admin-writtenCommitteeAssignmenttable. The
constantROLEdefault preserves every old-colour insert/read assumption;
there is no backfill, destructive SQL, or hot-table match.20260709120000_add_lodge_is_defaultadds a constant-default flag to the
tinyLodgesettings table, backfills one row, adds a partial unique index,
and replacesdefault_lodge_id()with an old-behaviour-compatible resolver.
Its migration comments record the ordering dependency on the preceding
timestamp repair; it contains no breaking/hot-table match.20260710120000_add_lodge_bed_typeadds a new enum and constant-default
bedTypeplus nullablebunkGroupto the cold lodge-bed inventory. Old
colours see every existing/new omitted bed type asSINGLE; no row rewrite
or destructive operation is involved.20260710140000_add_bed_allocation_second_occupantrelaxes the bed-night
uniqueness on the non-hotBedAllocationtable, adds constant-default
columns, backfills the denormalised type, and installs replacement/partial
unique indexes. Old-colour inserts remain primarySINGLEoccupants and
therefore retain the former one-row-per-bed-night behaviour. Run during
low bed-allocation admin activity for the index swap/backfill, but no
breaking-migration override or ledger row is required.
- The contract migrations that remove induction, finance-report, and legacy
email-lodge fields require the quiet/drained old-colour window described in
docs/UPGRADING.mdanddocs/BLUE_GREEN_MIGRATION_SAFETY.tsv. - The maximum sleeping-capacity fix can reduce bookable capacity when a lodge
has more active beds than its configuredLodgeSettings.capacity. Audit it
before deployment withdocs/CAPACITY_MODEL.md. - Configuration Export & Import is for configuration portability, not disaster
recovery. Continue to use and restore-testpg_dumpbackups.
Upgrade and verification
Follow docs/UPGRADING.md from v0.10.1 to v0.11.0. In summary: restore-test
a fresh backup, review every pending migration against the safety ledger, audit
capacity and default-lodge intent, deploy in a quiet low-write window, cut over
promptly through the documented override path, then verify lodge scoping,
capacity, module/member access, booking/bed-allocation operational views,
finance/Xero reads, email lodge identity, and the application theme.
This release does not publish an npm package (package.json remains private).
The supported artefacts are the Git tag/GitHub release and the repository's
container-image release workflow.
Publication evidence
- Release commit:
6161e6a5824dd03626edbf41d6f3924ae030e2df - Release PR: #1854 (merge commit; all required checks green)
- Main CI: run
29211672529— verify, migration drift, static analysis, secret scanning, Docker image security, and GHCR publish passed - Main E2E: run
29211672504— Playwright E2E and E2E multi-lodge passed - Main CodeQL: run
29211672220— passed - App image:
ghcr.io/thatskiff33/alpineclubbookingsnz-app:6161e6a5824dd03626edbf41d6f3924ae030e2df- OCI index digest:
sha256:9fcc4659c5a3c794e067e1dc4b59a749aa6d65fb5f4bda4a9abf6f5d4a5887bb
- OCI index digest:
- Migrate image:
ghcr.io/thatskiff33/alpineclubbookingsnz-migrate:6161e6a5824dd03626edbf41d6f3924ae030e2df- OCI index digest:
sha256:73528bac0698394aed71c1f8907cb49a005de27957ad35ae6d665c465111b358
- OCI index digest:
Maintainability follow-up
- No release-blocking follow-up remains. Continue tracking the non-blocking hotspots documented in
docs/MAINTENANCE.md.
This release does not publish an npm package because package.json remains private.