Track HiveGrid Cloud planning reference

This commit is contained in:
david committed 2026-06-26 20:48:01 +02:00
1 parent b3d5ea6764
commit e341c5938a
5784 files changed
+1104929 -3

No files matched your search

+110
View File
@@ -0,0 +1,110 @@
# 2026-01 release entry template
## Release summary
- **Release window:** 2026-01
- **Planned version/tag:** To be assigned when the release is cut.
- **SemVer decision:** Patch, minor, or major must be selected according to [docs/versioning.md](../versioning.md) before tagging. Use major for breaking changes, minor for backward-compatible additions or deprecations, and patch for backward-compatible fixes or documentation corrections.
- **Changelog source:** Align this entry with [CHANGELOG.md](../../CHANGELOG.md) before release cut.
- **Upgrade guidance:** Confirm affected operators can follow [docs/upgrade.md](../upgrade.md) and the detailed [upgrade runbook](../upgrades.md).
## Changelog alignment
### Added
- No changes recorded yet for this category.
### Changed
- No changes recorded yet for this category.
### Deprecated
- No deprecations recorded yet for this category.
### Removed
- No removals recorded yet for this category.
### Fixed
- No fixes recorded yet for this category.
### Security
- No security-specific changes recorded yet for this category.
## Pre-release checklist
- [ ] Release scope matches the relevant `CHANGELOG.md` entry and all Keep a Changelog categories are complete.
- [ ] SemVer decision is documented and reviewed against `docs/versioning.md`.
- [ ] Upgrade, migration, and rollback notes are documented for deployability, data, configuration, provider, and security-affecting changes.
- [ ] Documentation links were checked and no unresolved local links or unresolved marker text remain.
- [ ] Secrets, credentials, tenant identifiers, customer data, provider payloads, screenshots, and production connection strings are redacted from release evidence.
- [ ] Manual runtime checks are identified with owner, environment, expected evidence, and stopping criteria.
## Release-cut checklist
- [ ] Version or release window is final.
- [ ] Artifact/tag evidence is recorded with immutable references where available.
- [ ] `CHANGELOG.md` has the matching release notes and date.
- [ ] Release notes call out breaking changes, migrations, deprecations, and security fixes when present.
- [ ] Supported automated verification commands completed or failures are documented with owner and follow-up.
- [ ] Manual checks are not represented as automated verification.
## Post-release checklist
- [ ] Published artifact, tag, or deployment reference was confirmed by the release owner.
- [ ] Support, operations, and maintainer handoff notes were updated.
- [ ] Rollback readiness was reviewed after release cut.
- [ ] Post-release monitoring or manual runtime checks were recorded with redacted outcomes.
- [ ] Follow-up defects, documentation corrections, and migration work were linked from the release record.
## Verification evidence
Record supported non-E2E automated verification here. Use only repository-supported commands such as:
```sh
pnpm run typecheck
pnpm run lint
pnpm run verify:release-docs-baseline
pnpm run verify:docs-links
pnpm exec vitest run scripts/verify-release-docs-baseline.test.mjs
```
| Command | Owner | Date | Result | Notes |
| --- | --- | --- | --- | --- |
| `pnpm run verify:docs-links` | Pending assignment | Pending assignment | Pending | Required before release closure. |
| `pnpm run verify:release-docs-baseline` | Pending assignment | Pending assignment | Pending | Confirms release-checklist, changelog, artifact/tag, and production-readiness inventory terms. |
| `pnpm exec vitest run scripts/verify-release-docs-baseline.test.mjs` | Pending assignment | Pending assignment | Pending | Focused baseline-gate regression check. |
## Artifact/tag evidence
| Evidence type | Value | Owner | Date | Redaction notes |
| --- | --- | --- | --- | --- |
| Release tag | Pending assignment | Pending assignment | Pending assignment | Use immutable tag only; no credentials. |
| Commit SHA | Pending assignment | Pending assignment | Pending assignment | Use reviewed commit SHA. |
| Build artifact or image digest | Pending assignment | Pending assignment | Pending assignment | Use immutable digest or build ID; no registry credentials. |
| Release notes URL or ID | Pending assignment | Pending assignment | Pending assignment | Public or internal URL must not expose tokens. |
## Rollback notes
- **Rollback type:** Mark as redeploy-only, migration-sensitive, backup-dependent, or unsupported after release scope is known.
- **Previous known-good artifact:** Pending assignment.
- **Database or migration impact:** Pending assignment; if migrations are involved, confirm backup or restore-point readiness before production deployment.
- **Operational stopping point:** Stop before live deployment, provider change, or irreversible migration if required evidence is missing.
- **Redaction rule:** Rollback notes may include target name, tag, reviewed version, status, request ID, job ID, and redacted diagnostic code only.
## Manual checks
Manual checks are required for browser, Playwright, Cypress, E2E, production deploy, live Docker, live registry, Coolify, provider-console, or other runtime-only activities. Do not list these as automated checks.
| Manual check | Owner | Environment | Result | Redacted evidence |
| --- | --- | --- | --- | --- |
| Browser smoke journey | Pending assignment | Pending assignment | Pending | Record route and outcome only; no cookies or screenshots with customer data. |
| Production deployment or Coolify review | Pending assignment | Pending assignment | Pending | Record immutable artifact/tag and redacted health outcome. |
| Provider-console or live registry review | Pending assignment | Pending assignment | Pending | Record status and request/reference ID only; no provider payloads or credentials. |
## Negative verification expectations
Release verification must reject missing release files, unresolved local links, and unresolved marker text. Release entries must not rely on unsupported commands or claim automatic browser, Playwright, Cypress, registry, provider-console, production deploy, or E2E execution.
+58
View File
@@ -0,0 +1,58 @@
# Release documentation
## Purpose
This directory is the canonical release documentation root. Each release entry connects the user-facing [CHANGELOG.md](../../CHANGELOG.md), the [SemVer policy](../versioning.md), upgrade guidance in [docs/upgrade.md](../upgrade.md), and the deeper [upgrade runbook](../upgrades.md) to the evidence maintainers need before cutting, tagging, publishing, or rolling back a release.
Use this directory for release-checklist records, artifact/tag evidence, production-readiness notes, changelog alignment, and manual runtime boundaries. It does not replace the changelog; the changelog remains the concise public record, while release entries preserve operator evidence and decision context.
## Entry naming
Create one Markdown file per release window or version:
- `YYYY-MM.md` for a dated release train or initial planning template, for example [`2026-01.md`](./2026-01.md).
- `vMAJOR.MINOR.PATCH.md` when the release is cut around a specific SemVer version and the tag already exists or is being prepared.
Prefer immutable version names once a release is tagged. If a dated planning entry becomes a tagged release, either rename it in the same change that updates references or keep the dated entry as the planning record and link the final versioned entry from it.
## Required sections
Every release entry must include:
- Release summary and SemVer decision.
- Changelog alignment with Keep a Changelog categories: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, and `Security`.
- Pre-release checklist for readiness, unresolved risks, migrations, redaction review, and documentation links.
- Release-cut checklist for version, artifact/tag, changelog, and release notes evidence.
- Post-release checklist for monitoring, support handoff, rollback readiness, and follow-up work.
- Verification evidence limited to supported non-E2E automated commands.
- Artifact/tag evidence with immutable references when available.
- Rollback notes that state whether rollback is redeploy-only, migration-sensitive, backup-dependent, or unsupported.
- Manual checks for browser, Playwright, Cypress, provider-console, production deploy, live registry, live Docker, Coolify, or other runtime-only verification.
## Changelog and SemVer alignment
Release entries must agree with [CHANGELOG.md](../../CHANGELOG.md) and [docs/versioning.md](../versioning.md). Breaking changes require a major version decision, migration steps, rollback notes, and explicit verification evidence. Backward-compatible additions normally use a minor version, while backward-compatible fixes and documentation corrections normally use a patch version.
Do not leave unresolved marker text in release entries. Empty Keep a Changelog categories should say that no changes were introduced for that category.
## Supported automated verification examples
Only use commands that are present in `package.json` or explicit focused Vitest targets that are supported by the repository:
```sh
pnpm run typecheck
pnpm run lint
pnpm run verify:release-docs-baseline
pnpm run verify:docs-links
pnpm exec vitest run scripts/verify-release-docs-baseline.test.mjs
```
Do not claim registry pushes, production deploys, provider-console checks, browser sessions, Playwright, Cypress, or E2E runs as automatic checks in release entries. Record those as manual checks with owner, date, environment, and redacted outcome when they are required.
## Artifact and tag evidence
Artifact/tag evidence should name immutable references such as release tag, commit SHA, image digest, package version, build job URL or ID, and signed artifact status when available. Evidence must be redacted: do not include secrets, bearer tokens, cookies, customer data, provider payloads, private registry credentials, production connection strings, or screenshots containing sensitive information.
## Manual runtime boundary
Automatic release documentation verification stays inside non-E2E checks: file/content assertions, docs-link checks, typecheck, lint, and focused Vitest. Production deploys, live Docker or registry operations, Coolify checks, browser journeys, Playwright, Cypress, provider consoles, and live customer-impacting verification require a human-approved manual runtime record.