Roadmap

Plumego is designed to be boring, stable, and long-lived.

The roadmap does not describe a flood of upcoming features.
Instead, it defines:

Where Plumego may evolve
Where it explicitly will not
What principles constrain all future changes

This page exists to prevent false expectations.

What the Roadmap Is

The Plumego roadmap is:

Directional, not tactical
Principle-driven, not feature-driven
Conservative by default
Explicit about non-goals

It helps you answer:

“If I build on Plumego today, will it still make sense in five years?”

What the Roadmap Is Not

The roadmap is not:

A release plan
A sprint backlog
A feature promise
A marketing page

If something is not implemented yet,
this page does not guarantee it ever will be.

Core Direction: Stability Over Expansion

The primary long-term goal of Plumego is:

To remain small, explicit, and stable.

This means:

Fewer core features over time
Slower release cadence
Higher bar for change
Strong backward compatibility

Growth happens at the edges, not in the core.

Areas of Intentional Stability

The following areas are considered largely complete:

Request lifecycle model
Context semantics
Middleware execution model
Routing model
HTTP server integration
Explicit dependency wiring philosophy

Changes here are extremely unlikely
outside of major-version releases.

Possible Areas of Evolution

These areas may evolve cautiously,
without violating core guarantees.

1. Ergonomic Improvements

Small API refinements
Better naming clarity
Reduced boilerplate helpers
Improved error messages

These changes must not introduce hidden behavior.

2. Documentation and Examples

More real-world examples
Expanded reference coverage
Better migration guides
Deeper operational documentation

Documentation is considered a first-class surface.

3. Optional Ecosystem Packages

Instead of growing the core, Plumego may gain:

Companion middleware packages
Optional adapters
Reference implementations
Example integrations

These live outside the core repository
and do not affect core stability.

4. Tooling and Developer Experience

Potential areas include:

Linting rules for Plumego usage
Project templates
Static analysis helpers
Debugging aids

Tooling must not require runtime framework changes.

Explicit Non-Goals

The following are deliberate non-goals.

Plumego will not become:

A full-stack framework
An ORM
A DI container
A background job framework
An API gateway
A service mesh
A policy engine
A configuration framework

If you need these, Plumego should integrate with them —
not replace them.

Feature Requests and the Roadmap

When evaluating new ideas, the guiding questions are:

Does this preserve explicit control flow?
Does this avoid hidden behavior?
Does this belong in user code instead?
Does this reduce long-term maintenance cost?

If the answer to any is “no”,
the feature likely does not belong in the core.

Versioning Philosophy

Plumego follows semantic versioning:

Patch releases: bug fixes only
Minor releases: additive, backward-compatible changes
Major releases: rare, deliberate, breaking changes

Major releases are expected to be infrequent.

Community Influence

Community input is welcome — but filtered through discipline.

Plumego prioritizes:

Long-term maintainability
Conceptual integrity
Architectural clarity

Popularity-driven decisions are explicitly avoided.

Migration and Longevity

Plumego is designed so that:

Old code continues to work
Upgrades are predictable
Large refactors are unnecessary
Knowledge remains transferable

Framework churn is treated as a failure mode.

Summary

The Plumego roadmap is defined by restraint.

Fewer features
Clearer boundaries
Slower change
Longer lifespan

If Plumego ever becomes exciting because of constant new features,
it has likely failed its original goal.

From here, useful next reads include:

Changelog — what has actually changed
Migration Guides — when breaking changes occur
Contributing — how evolution decisions are made

The roadmap defines the future by defining its limits.