Goal: A simple, memorable, canonical, public timetable to be used for community communication (READMEs, blog posts, etc), not for internal planning.
Purpose: State our commitment to end users to improve their experience in knowing how and when to plan their own infra decisions related to Flux.
When | Flux 2 | Flux 1 |
---|---|---|
Oct 6, 2020 | CLI: Development mode 1 (follows semver) APIs and Controllers: v1alpha1 (follow k8s release style). See Roadmap for component versions.
|
Maintenance Mode
|
Feb 18, 2021 | CLI: development mode APIs and Controllers: some v1beta1, some v2beta1, some v1alpha1
|
Partial Migration Mode
|
DATE TBD (target date ?) All Flux components production-ready except CLI may still get breaking changes as we support users |
CLI: dev mode APIs & Controllers: some v1beta1, some v2beta1, major change Image Updates will be v1beta1
|
Superseded
|
DATE TBD (can we commit to a specific support window from this date (e.g., 6 months)? |
Public release CLI: MAJOR release APIs and Controllers: some v1, some v2, some still in v1betaX
|
Migration and security support only
|
DATE TBD | Continuing active development
|
Archived |
1 Flux 2 versioning requires a more complex answer than Flux 1 versionsing, because it is no longer a monolithic application. We do however coordinate component versions for cross-compatibility. When we tag the Flux CLI version, we bundle in that CLI version API and Component versions that are tested together with end-to-end tests. You may safely upgrade from one PATCH version to another.
- Make the version guarantees very clear in the Roadmap
- Add CLI to this matrix. Also add Terraform (those who don’t use CLI, but only Terraform provider)
- In dev mode, you may also install Flux with just kubectl (then create git repo history on cluster, then place file you created with kubectl in your git repo)
- Add a note explaining why we use two different versioning schemes (1. semver for Flux CLI, and 2. k8s API style versioning for Flux APIs and Controllers)
Moved to fluxcd/flux2#1036