---
title: "Roadmap"
description: "Current focus areas and planned direction for RoomSharp."
canonical: "https://roomsharp.dev/docs/v0.5.4/roadmap"
source: "src/content/v0.5.4/roadmap.mdx"
---
# Roadmap
RoomSharp's roadmap is intentionally conservative. The 0.5.x line is focused on reliability, generated-code quality, provider consistency, and documentation rather than large API expansion.
## Current Focus: 0.5.x Stabilization
The current release line is centered on making the existing ecosystem dependable in real projects:
- Generated DAO correctness across serialized and parallel concurrency modes.
- Transaction/session behavior across runtime helpers, seeders, relation loaders, and QueryExtensions.
- Provider-aware SQL generation for SQLite, SQL Server, PostgreSQL, and MySQL.
- Lifecycle features: soft delete, global filters, encrypted properties, audit fields, and query cache behavior.
- CLI workflows for inspection, scaffolding, migrations, schema export, and verification.
- Documentation alignment across the website, package READMEs, samples, and release notes.
- Focused tests for source generation, runtime behavior, QueryExtensions, and provider-sensitive SQL.
The priority for the 0.5.x line is stability and adoption polish. New features are accepted only when they strengthen existing workflows or close clear product gaps.
## Near-Term Work
- Continue expanding practical examples for dependency injection, QueryExtensions, reactive queries, and CLI usage.
- Add more provider-specific validation around migrations, FTS helpers, locking behavior, and generated SQL.
- Improve diagnostics for source generator errors and unsupported API combinations.
- Keep benchmark coverage representative of generated DAO, QueryExtensions, bulk insert, and transaction-heavy paths.
- Refine documentation for advanced scenarios such as relation loading, filtered includes, caching, and multi-provider deployments.
## Mid-Term Direction
- Provider-level optimizations based on real usage and benchmark data.
- QueryExtensions ergonomics around composable includes, raw SQL, streaming, and transaction-aware sessions.
- CLI polish for team workflows: repeatable schema verification, migration review, and project inspection.
- Better guidance for packaging, version alignment, and upgrade paths across the RoomSharp ecosystem.
## Deferred Work
Native AOT support is intentionally deferred until the current runtime and generated-code surface is fully stable.
RoomSharp has an internal AOT plan, but the project should not claim Native AOT support until there is a tested, documented support profile with a clear compatibility matrix.
Other demand-driven areas:
- Full runtime FTS integration beyond guarded metadata/dialect helpers.
- Advanced provider-specific capabilities where they provide clear value and can be documented consistently.
- Additional UI binding packages only when they can stay thin and predictable on top of the reactive layer.
## Design Philosophy
RoomSharp deliberately avoids feature creep. New capabilities are added when they align with the project's core goals:
- predictable generated code,
- high-performance runtime paths,
- provider-aware SQL behavior,
- clear integration with dependency injection and application architecture,
- documentation that matches the implementation.
## API Stability Notice
RoomSharp is pre-1.0, so targeted API refinements can still happen.
The core concepts and architecture are stable enough for real projects when versions are pinned and release notes are reviewed before upgrades.
Breaking changes, when needed, are documented in release notes with migration guidance where possible.
For package compatibility and release cadence, see the [Release Model](/docs/v0.5.4/release-model). For completed work, see the [Changelog](/docs/v0.5.4/changelog).