103 lines
4.3 KiB
Markdown
103 lines
4.3 KiB
Markdown
# Roadmap
|
|
|
|
This directory contains only future, deferred, or aspirational work for
|
|
`distributor`. Implemented behavior is documented in the current user,
|
|
operator, internal, policy, integration, and example documentation:
|
|
|
|
- `README.md`
|
|
- `docs/cli.md`
|
|
- `docs/config.md`
|
|
- `docs/operations.md`
|
|
- `docs/troubleshooting.md`
|
|
- `docs/internal/`
|
|
- `docs/integrations/markdown.md`
|
|
- `docs/policy/`
|
|
- `examples/`
|
|
|
|
`distributor` currently supports local, SSH/SFTP, and S3-compatible source and
|
|
destination backends; producer bundle creation through `pkg/bundle` and
|
|
`distributor manifest create`; configured source validation and inspection;
|
|
Markdown sidecar and `index.html` publication; archive and fixed destination
|
|
path mapping; destination link metadata; shared text/JSON CLI output; and
|
|
managed destination replacement behavior.
|
|
|
|
## Future Work
|
|
|
|
These items are not implemented. They should not be documented as current
|
|
behavior outside `docs/roadmap/` unless a future implementation adds them.
|
|
|
|
### CLI And Status Output
|
|
|
|
- Add a root-global output flag only if the command parser is later refactored
|
|
around shared root options.
|
|
- Add output formats beyond `text` and `json` only if a concrete consumer
|
|
requires them.
|
|
- Add a versioned JSON schema reference after the first JSON-capable release.
|
|
- Add destination-state inspection behind an explicit flag such as
|
|
`--with-destinations` if operators need fan-out status diagnostics from
|
|
`inspect`.
|
|
- Add additional status or inspection presentation for destination primary
|
|
links beyond the current `run --format json` result model.
|
|
|
|
### Producer Workflows
|
|
|
|
- Add a no-write manifest creation mode, such as writing manifest JSON to
|
|
stdout, if producer pipelines need to capture manifests directly.
|
|
- Add broader producer workflow helpers, such as richer ignore rules or
|
|
template scaffolding, if real producer use cases require them.
|
|
- Add remote or storage-backed producer writers only if producer applications
|
|
need to assemble bundles outside the local filesystem.
|
|
|
|
### Publication And Transform Behavior
|
|
|
|
- Add a separate collection or site-index transform if distributor needs
|
|
multi-page aggregation.
|
|
- Add richer transform metadata only if future state consumers need more than
|
|
the transform name and output path.
|
|
- Add custom HTML index output names only if fixed `index.html` is too limiting
|
|
for real deployments.
|
|
- Add richer fixed-destination source selection policies if deployments need
|
|
something other than newest-by-`created`.
|
|
- Add stricter handling for equal latest timestamps if timestamp ties become
|
|
common in producer workflows.
|
|
- Add higher-level status or approval workflows for fixed-root replacements if
|
|
dry-run output is not enough operational protection.
|
|
- Add richer link policies only if `auto`, `html`, and `source` prove
|
|
insufficient.
|
|
|
|
### State And Compatibility
|
|
|
|
- Define a post-release destination state schema bump policy before introducing
|
|
materially incompatible state changes.
|
|
- Add warning-only digest mismatch handling only if an operator workflow needs
|
|
publication to continue after validation failures.
|
|
- Add compatibility parsing for legacy SSH URI config only if migration support
|
|
is required.
|
|
|
|
### Backends, Security, And Deployment
|
|
|
|
- Add authentication mechanisms beyond the implemented SSH agent/key and S3
|
|
credential paths only when a concrete backend workflow requires them.
|
|
- Add broad recursive destination deletion outside managed bundle paths only if
|
|
a future design can preserve the current safety boundary.
|
|
- Add concurrent fan-out publishing only if runtime profiling shows it is
|
|
needed.
|
|
- Add streaming, resumable, or multipart S3 uploads only if object sizes make
|
|
the current write path insufficient.
|
|
- Add cloud-provider-specific IAM integration docs only when the repository
|
|
includes tested provider-specific behavior.
|
|
- Add repository-managed packaging, release, and deployment automation when the
|
|
release process is ready to be standardized.
|
|
|
|
## Roadmap Maintenance
|
|
|
|
When adding future roadmap work:
|
|
|
|
- describe user-visible behavior and safety boundaries;
|
|
- define which current docs must change after implementation;
|
|
- keep examples secret-free and runnable or clearly environment-gated;
|
|
- keep workflow labels out of production code, tests, config fields, and
|
|
user-facing documentation;
|
|
- run focused tests for the changed behavior and `go test ./...` for
|
|
cross-package changes.
|