Skip to content
Zarf

Roadmap

The issue board for Zarf is hosted on a GitHub Project Board that tracks the issues the Zarf team is working along with future work we are prioritizing.

If you would like to add bug reports or feature requests, please add an issue to the GitHub repository under the appropriate template. If you have a more general question about a feature, feel free to ask the team in the Zarf Kubernetes Slack Channel.

We also accept contributions from the community (regardless of where a particular bug or feature is in the queue), so feel free to read our contributing guidelines and submit a PR! You can also ask any development related questions in the Zarf Dev Kubernetes Slack Channel.

  • - Establish a monthly community meetup to engage members of the community and answer questions.
  • - Refactor and add tests to library code shared with UDS-CLI and split into a new GitHub repository.
  • - Gather OpenSSF donation requirements and clear off pre-reqs (additional maintainers and sponsor working group).

  • - Consolidate and improve consistency around features such as Zarf variables and component required schema.
  • - Move docs website from Docusaurus to a different framework to improve maintainability going forward.
  • - Finalize and submit Zarf’s sandbox application to officially join the OpenSSF.

  • - Transfer project and additional repos (zarf-ui, zarf-init-aws, setup-zarf, etc.) to a new GitHub organization.
  • - Stabilize features after the consolidation of Q2 - clean up GA milestone in preparation for Q4.
  • - Flesh out the extension system for new features / experiments to be more smoothly integrated with Zarf.
  • - Make zarf init custom logic definable in-schema and across all packages.

  • - Continue stabilizing features and interfaces in preparation for GA release.
  • - Gather and prepare to meet OpenSSF’s incubation requirements.
  • - Officially cut a GA v1.0.0 release of Zarf.

Zarf has three levels of feature stability that are defined below but generally follow existing Kubernetes conventions. These communicate how a feature may change in the future as well as expectations for *ilities like documentation.

Alpha features act as early previews for things that are being considered for inclusion into Zarf and:

  • they are very likely to have breaking changes (or be removed entirely) in future versions of Zarf
  • they will have limited documentation beyond autogenerated CLI and schema documentation (questions should be directed to the Zarf team)
  • they will have limited testing and are only recommended for use cases where the risk of instability is acceptable

Beta features are newer features that are being prepared to eventually become stable features and:

  • they may introduce breaking changes before release, but will include any applicable workarounds
  • they will have documentation beyond autogenerated docs, but it won’t be fully complete
  • they will have tests that cover their core features, but not covering every flavor of environment

Stable features are features that the Zarf team has committed to maintaining stability for and:

  • they will have backwards compatibility shims introduced in lieu of breaking changes
  • they will have autogenerated docs, tutorials/tutorial mentions, examples, and core docs
  • they will have tests that cover the feature which will run across all tested environments

Deprecated features are features that are no longer recommended for use and:

  • they will have a deprecation notice in the documentation + CLI
  • they will have a timeline for removal (currently all deprecated features will be removed in the next major release of Zarf)
  • they will have a recommended alternative

Right now, Zarf itself is still in its ‘beta’ phase. We are working on some final things before we release the official 1.0 General Availability (GA) release. The work still needed for the GA release can be found in our issues with this filter.

We are currently targeting Q4 2024 to have Zarf be generally available and will be pushing weekly releases until then to add necessary features and fix bugs as well as improve docs, architecture and test coverage behind the scenes.