RustProxy/ROADMAP.md

RustProxy roadmap

This file records work still requiring acceptance or planned future consideration, rather than repeating completed release history. Implemented functionality is described in the documentation, and operator-visible changes by release are in the changelog.

0.34.1 — outstanding development acceptance

• Build with the project's required Rust toolchain and run the full unit and integration test suite.
• Verify --config concurrent edit rejection, file permissions, atomic writes, migration and restore, plus systemd reload on a running install.
• Exercise RO/RW API token allowlists and IP/HTTPS enforcement, token revocation, Prometheus rotation/revocation (including legacy environment-token fallback), and unauthorized requests.
• Verify certificate bulk assignment, Dashboard layout save/lock behavior, and all existing HTTP/TLS proxy test cases.

0.34.0 — outstanding release verification

• Compile the exact 0.34.0 source candidate on the supported target environments and run the current Rust regression suite.
• Exercise full HTTP/1.1, TLS, HTTP/2, HTTP/3, WebSocket, frontend/backend routing, retry, cache/privacy, certificate and administration scenarios.
• Test selective HOT/COLD invalidation through configuration edits, restart and persistent cache recovery; verify related regression cases and migration behavior.
• Verify optional Linux sendfile=auto with eligible static files and that all ineligible requests use safe normal delivery.
• Run controlled before/after performance and resource measurements. No 0.34.0 throughput improvement is established yet.
• Perform backup/restore and managed install/update acceptance on supported systems, including the container deployment where applicable.

Longer-term directions

Future work must be tracked separately from shipped features. Potential areas include better operational verification, additional diagnostics/alerting, clearer configuration and migration UX, and compatibility work as HTTP/ACME/runtime dependencies evolve. These are not commitments or implemented features without a separately tested release.

Documentation policy

• Update existing guides when code behavior changes; remove obsolete instructions and avoid version-by-version implementation notes inside functional guides.
• Keep the changelog technical from an operator's perspective (features, settings, compatibility, defaults, fixes) without Rust allocation/lock/microbenchmark details.
• Preserve old audit/development evidence in a separate archival package if an engineering investigation requires it, not in the live product Reader.