30 lines
2.6 KiB
Markdown
30 lines
2.6 KiB
Markdown
# 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](docs/README.md), and operator-visible changes by release are in the [changelog](CHANGELOG.md).
|
|
|
|
## 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.
|