Skip to content

docs: stop describing DevCloud as pre-1.0 in what the release archive ships #130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
skyoo2003 merged 2 commits into from
Aug 10, 2026
Merged

docs: stop describing DevCloud as pre-1.0 in what the release archive ships #130

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1c6425f
docs: stop describing DevCloud as pre-1.0 in what the release archive…
skyoo2003 Aug 10, 2026
a03e410
docs: align the architecture phase markers with the roadmap
skyoo2003 Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,14 @@

DevCloud is a small, volunteer-driven open-source project. This document describes how decisions are made and how the roles evolve as the project grows.

## Current state (0.x)
## Current state

- **Benevolent maintainer model.** One maintainer ([@skyoo2003](https://github.com/skyoo2003)) has final say on roadmap, releases, and merge decisions.
- **Apache License 2.0.** All contributions are accepted under this license; see [CONTRIBUTING.md](CONTRIBUTING.md).
- **Best-effort response.** No SLA; see [SUPPORT.md](SUPPORT.md) for expectations.

This is appropriate while the project is pre-1.0 and scope is still being proven.
This is appropriate at the project's current size. It is a statement about who decides, not about
API stability — what a release promises is [docs/compatibility-policy.md](docs/compatibility-policy.md).

## How decisions are made

Expand Down
5 changes: 5 additions & 0 deletions changes/unreleased/Documentation-20260811-140000.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
kind: Documentation
body: The roadmap, architecture and governance docs no longer describe DevCloud as pre-1.0. All three ship inside the release archive, so a v1.0 download would have carried a roadmap listing its own release as pending, an architecture overview naming Phase 1 as current, and a governance doc calling the API unstable — contradicting the compatibility policy packaged beside them
time: 2026-08-11T14:00:00.000000+09:00
custom:
Issue: "130"
4 changes: 2 additions & 2 deletions docs/architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ DevCloud's long-term direction is to support multiple Cloud Service Providers (A

A phased refactor is planned (see [roadmap.md](roadmap.md)):

- **Phase 1 (current)** — AWS services via Smithy codegen, single-port gateway, AWS SigV4 auth.
- **Phase 2 (preparation)** — Introduce an Intermediate Representation (IR) between API models and codegen. Abstract `ModelSource` so OpenAPI (Azure) and Protocol Buffers / Discovery Documents (GCP) can feed the same pipeline. Extract a per-provider auth adapter interface.
- **Phase 1 (complete, shipped as v1.0)** — AWS services via Smithy codegen, single-port gateway, AWS SigV4 auth.
- **Phase 2 (current)** — Introduce an Intermediate Representation (IR) between API models and codegen. Abstract `ModelSource` so OpenAPI (Azure) and Protocol Buffers / Discovery Documents (GCP) can feed the same pipeline. Extract a per-provider auth adapter interface.
- **Phase 3 (pilot)** — First non-AWS service (candidate: Azure Blob Storage) validates the multi-CSP architecture.
- **Phase 4 (breadth)** — Additional services across CSPs; community-owned providers.

Expand Down
10 changes: 5 additions & 5 deletions docs/roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ We pursue this vision through a **phased rollout** to manage scope, architectura

## Phases

### Phase 1 — AWS Depth & Stabilization (Current, targeting v1.0)
### Phase 1 — AWS Depth & Stabilization (Complete, shipped as v1.0)

**Goal**: mature the already-broad AWS surface into a stable, well-tested v1.0.

Expand All @@ -27,9 +27,9 @@ We pursue this vision through a **phased rollout** to manage scope, architectura
- [x] boto3 compatibility coverage added for previously-untested services (CodeConnections, DMS, Verified Permissions)
- [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

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep the v1.0 release pending until it is published

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 👍 / 👎.


### Phase 2 — Architectural Preparation (v1.x)
### Phase 2 — Architectural Preparation (Current, v1.x)

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Update the architecture phase marker as well

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 👍 / 👎.


**Goal**: internal refactor so adding a new CSP doesn't require forking the project.

Expand Down Expand Up @@ -75,7 +75,7 @@ We pursue this vision through a **phased rollout** to manage scope, architectura

| Version | Focus |
|---------|-------|
| 0.x ← current | AWS services, unstable API |
| 1.x | AWS depth, stable plugin API |
| 0.x | AWS services, unstable API |
| 1.x ← current | AWS depth, stable plugin API |
| 2.x | Multi-CSP architecture, Azure pilot |
| 3.x+ | Broad CSP coverage, community-owned providers |