docs: stop describing DevCloud as pre-1.0 in what the release archive ships - #130
Conversation
… ships The archive carries the docs/ tree and GOVERNANCE.md (#127), and v1.0 is the first tag where that is true. Unpacked, it would have handed a user a roadmap listing v1.0 as pending and a governance doc calling the API unstable, beside a compatibility-policy.md stating what 1.x guarantees. Phase 1 is marked complete, the version table's current marker moves to 1.x, and the governance note now says what it meant — how decisions are made, not how stable the API is.
github-actions
Bot
added
the
documentation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c6425f654
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - [x] Stable `ServicePlugin` API finalized and documented ([plugin-api.md](plugin-api.md)), enforced by a conformance test over every registered service | ||
| - [x] Generic CRUD fallback engine ([crud-engine.md](crud-engine.md)) auto-serves ~2,200 CRUD-shaped operations across all 46 JSON-protocol services with plausible, store-backed responses; every registered JSON service is wired. **Follow-up**: promote high-value auto-crud ops to hand-verified fidelity. | ||
| - [ ] v1.0 release (pending maintainer tag) | ||
| - [x] v1.0 release — see [compatibility-policy.md](compatibility-policy.md) for what 1.x guarantees |
There was a problem hiding this comment.
At this commit, CHANGELOG.md still identifies v0.2.0 as the latest release and there is no batched changes/v1.0.0.md; the documented release process only produces the actual release after that file is committed and its matching tag is pushed (docs/release.md, lines 98–106). Consequently, checking this box makes the repository claim that v1.0 has shipped before the required release commit or tag exists. Keep this pending (or describe the phase as ready for v1.0) until the release is actually published.
Useful? React with 👍 / 👎.
| - [x] v1.0 release — see [compatibility-policy.md](compatibility-policy.md) for what 1.x guarantees | ||
|
|
||
| ### Phase 2 — Architectural Preparation (v1.x) | ||
| ### Phase 2 — Architectural Preparation (Current, v1.x) |
There was a problem hiding this comment.
Marking Phase 2 as current leaves the linked architecture overview contradicting the roadmap: docs/architecture.md line 9 still labels Phase 1 as current, while line 10 presents Phase 2 only as preparation. Readers following the roadmap's architecture link therefore get two different answers about the active phase; update those phase labels alongside this transition.
Useful? React with 👍 / 👎.
Moving the roadmap's current marker to Phase 2 left architecture.md line 9 still naming Phase 1 as current, so the two docs — both packaged in the release archive — gave different answers to which phase is active.
1 participant
Why
.goreleaser.yamlpackages thedocs/tree andGOVERNANCE.mdinto every archive — added in #127 and not yet in any release. v1.0 is the first tag where these become user-facing artifacts rather than repo files.Unpacking
devcloud_v1.0.0_linux_amd64.tar.gztoday would hand a user:docs/roadmap.md—- [ ] v1.0 release (pending maintainer tag), and0.x ← current | AWS services, unstable APIGOVERNANCE.md— "Current state (0.x)" … "while the project is pre-1.0"…sitting beside
docs/compatibility-policy.md, which states what 1.x guarantees. The archive would contradict itself.What changed
0.x ← current→1.x ← current, keeping the 0.x row as historyGOVERNANCE.mddrops the pre-1.0 framing — the benevolent-maintainer model is a statement about who decides, not about API stability, so it now points at the compatibility policy for the latterDocs only. No
internal/change.