Skip to content

Release Posture

Plumego v1 covers the checked-in repository, but not every area carries the same compatibility promise. This page exists so readers do not mistake a checked-in package, a generated fact card, or a reference-app mention for a blanket stability claim.

Synced from the v1 support matrix in `README.md`

6 Synced entries

ga

Stable library roots

Public package surface carries the v1 stable-root compatibility promise.

Modules: contract, core, router, middleware, security, store, health, log, metrics

supported reference

Canonical reference app

Kept aligned with the canonical bootstrap and stable-root usage, but not treated as a reusable extension catalog.

Modules: reference/standard-service

supported tool

CLI

Supported as a command-line tool, not as a Go import surface; command behavior and generated output must stay aligned with canonical docs.

Modules: cmd/plumego

beta

Beta extension families

API surface frozen between minor release refs; promoted after two consecutive tagged refs with no exported API changes and owner sign-off.

Modules: x/gateway, x/observability, x/rest, x/websocket, x/tenant, x/frontend, x/messaging

experimental

App-facing extension families

Included in repo quality gates and release scope, but API/config compatibility is not frozen.

Modules: x/fileapi, x/openapi, x/resilience, x/rpc, x/data, x/ai, x/validate

experimental

Subordinate extension primitives

Maintained and tested, but discovery should start from the owning family entrypoint and compatibility is not frozen.

Modules: x/ai/distributed, x/ai/filter, x/ai/instrumentation, x/ai/llmcache, x/ai/marketplace, x/ai/metrics, x/ai/multimodal, x/ai/orchestration, x/ai/prompt, x/ai/provider, x/ai/resilience, x/ai/semanticcache, x/ai/semanticcache/cachemanager, x/ai/semanticcache/embedding, x/ai/semanticcache/vectorstore, x/ai/session, x/ai/sse, x/ai/streaming, x/ai/tokenizer, x/ai/tool, x/data/cache, x/data/file, x/data/idempotency, x/data/kvengine, x/data/migrate, x/data/pgx, x/data/rw, x/data/sharding, x/data/sqlx, x/gateway/cache, x/gateway/discovery, x/gateway/ipc, x/gateway/protocol, x/gateway/protocolmw, x/gateway/transform, x/messaging/mq, x/messaging/pubsub, x/messaging/scheduler, x/messaging/webhook, x/observability/dbinsights, x/observability/devtools, x/observability/featuremetrics, x/observability/ops, x/observability/recordbuffer, x/observability/testlog, x/observability/testmetrics, x/observability/tracer, x/observability/windowmetrics, x/resilience/circuitbreaker, x/resilience/ratelimit, x/rest/versioning, x/rpc/client, x/rpc/gateway, x/rpc/server, x/tenant/config, x/tenant/core, x/tenant/policy, x/tenant/quota, x/tenant/ratelimit, x/tenant/resolve, x/tenant/session, x/tenant/transport

1

Default path

long-lived public surface

2

Service shape

supported example to copy from

3

Workflow surface

verify generated code against current APIs

4

Optional capability

wrap behind app-local adapters

5

Narrow detail

check module.yaml before adoption

Surface Adoption posture Compatibility reading
Stable roots Default path Read as the long-lived public surface, still bounded by each module manifest
reference/standard-service Supported reference Safe to copy as service shape, not as a repository ownership rule
CLI and scaffolding Supported workflow surface Useful for generation and examples; still verify generated code against current APIs
App-facing x/* family Optional extension Use when the capability fits; isolate behind app-local adapters for production paths
Subordinate x/* primitive Narrow extension detail Start from the primary family first; adopt only after checking the local package contract
Question Stronger signal Weaker signal
Is it part of the default path? Used by reference/standard-service Merely present in the repository
Is the API likely to stay narrow? Stable root plus module manifest scope Broad capability family with experimental status
Can I copy the example directly? Example uses current public symbols and stable roots Example crosses experimental extension boundaries
Should production code depend on it directly? Stable root contract Experimental x/* API without an application-local adapter
Signal Safer assumption
The package lives under x/* Treat it as an extension surface and check maturity
It is absent from reference/standard-service It is not part of the smallest canonical path
The work is capability-specific, topology-heavy, tenant-aware, or protocol-specific Start from the owning extension family
A guide or scaffold mentions it The mention explains usage; it does not upgrade compatibility posture

Plumego keeps release posture explicit so documentation, scaffolds, and extension work do not accidentally overstate compatibility. The point is not to make the repository feel uncertain; it is to keep the stable path narrow enough that readers know what can be copied with confidence.