mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: define v1 stabilization dev lane policy

Browse Source
This commit is contained in:
Codex
2026-05-19 03:47:19 +00:00
parent 9d46ca2531
commit f36ea37548
3 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/release-governance.md
+24
View File
@@ -40,6 +40,28 @@ UniDesk enters stabilization mode when core availability is threatened by contro
Exit from stabilization requires CI/CD, deploy verification, Code Queue recoverability and dev/prod isolation to be demonstrably healthy.
## V1 Stabilization Window
When `release/v1` is being stabilized, the current dev environment should be temporarily treated as the v1 validation lane. Do not add `dev-v1` and `dev-master` manifest lanes during the same window unless the absence of split lanes is the blocker for a v1 fix.
The temporary rule is:
- pause high-risk `master` feature and architecture work that would compete for dev, CI, Code Queue or deploy capacity;
- keep `origin/master:deploy.json#environments.dev` as the implemented command contract, but pin the relevant service commits to v1 stabilization commits when validating v1 fixes;
- document any temporary v1 pin in the related issue before relying on it;
- do not introduce dirty local manifests, hidden deploy refs, or implicit branch-based behavior;
- do not change `deploy.json` schema only to express the future split-lane target.
The v1 stabilization task should move through these phases:
1. Establish the v1 baseline from the last TypeScript backend-core commit and record which post-baseline fixes are candidates for backport.
2. Backport user-visible and operability fixes that preserve the existing architecture, especially Code Queue prompt/trace visibility, `/api/workdirs`, gateway diagnostics, and CI image-build stability.
3. Make the current dev lane validate v1 by pinning `environments.dev` service commits to the v1 fix set and running the existing dev/CI checks.
4. Promote only the verified v1 commits to production desired state through the normal commit-pinned deploy path.
5. After v1 is stable, implement explicit `dev-v1` and `dev-master` lanes or an equivalent schema, with CLI, CI, frontend labels, diagnostics and documentation updated together.
Code Queue can implement bounded v1 bug fixes, tests and documentation patches when the task can run in an isolated worktree and does not require production mutation. Manual control is required for branch creation, v1 baseline selection, `deploy.json` pin changes, production deploys, recovery actions on active tasks, and any decision to resume high-risk master work.
## CI/CD Runtime Versioning
CI/CD server and control-plane services are production-like infrastructure. Their runtime version must be pinned by `deploy.json` to the production desired commit, not implicitly follow the operator's local worktree or the latest `master`.
@@ -59,6 +81,8 @@ The target model is to separate a stable maintenance dev lane from a master inte
This split must be implemented explicitly in `deploy.json`, deploy planning, deploy apply, CI, frontend labels and diagnostics. Until that work is done, existing commands continue to read the currently documented manifest ref such as `origin/master:deploy.json#environments.dev`; operators must not simulate split lanes through dirty local manifests, hidden branches, or undocumented runtime edits.
During a v1 stabilization window, the future split-lane implementation is deliberately deferred. The current `environments.dev` lane is reserved for v1 validation until the v1 release criteria are met, then the explicit split-lane work can proceed as a separate infrastructure change.
## Feature Flags
Feature flags are short-lived risk controls, not a long-term architecture partitioning mechanism. Prefer release lines, service boundaries and deployment boundaries for durable divergence.