Skip to main content
Flyte is used in production at multiple companies. The community prioritizes stability, reliability, observability, and maintainability over raw feature velocity.

​
How the community works

Features are developed in response to specific use cases and user scenarios. The Flyte team also proactively plans for the evolution of the system. When rapid prototyping helps uncover hidden use cases or pitfalls, features may be developed behind feature flags before general availability.
To influence the roadmap, share your use cases with the community. The Flyte team adapts the platform to meet real requirements. Join Slack or open a GitHub Discussion to share your scenario.

​
Release cadence

Flyte aims to release quarterly, with the understanding that releases are driven by feature readiness rather than strict calendar dates. If features planned for a release are delayed, the release timeline shifts accordingly. This gives the team more time to beta-test each feature.

​
Versioning scheme

At each quarterly release:
  • All major components are released with an incremented minor version (e.g. 1.16.x → 1.17.0).
  • The major version remains 1 for the foreseeable future.
  • After a release, merges to master receive beta tags: the merge after v1.16.0 becomes v1.17.0b0.

​
Aligned components

These components are released together at each quarterly release:
ComponentRepository
FlytePropellerflyte monorepo
FlyteAdminflyte monorepo
FlyteConsoleflyte monorepo
DataCatalogflyte monorepo
flytectlflyte monorepo
Flytekitflyteorg/flytekit
flytekit-javaSeparate repo

​
Independently versioned components

These components are versioned on their own cadence:
  • flyteidl — Protobuf schema
  • flytestdlib — shared Go library
  • flyteplugins — execution plugins
  • flytecopilot — data sidecar

​
Helm charts

Helm chart versions are always identical to the Flyte release version down to the patch. A Flyte release is a Helm release and vice versa.

​
Release branches and patching

After each minor release, a release-vX.Y branch is created. Patch versions are independent per component: by the end of the 1.3.x cycle, flyteadmin might be at 1.3.8 while flytepropeller is at 1.3.2. Default workflow: Bug fixes are developed against master. After merge, the developer ports the fix to the appropriate release-vX.Y branch. Support window: We support one release back for regular bug fixes, and two releases back for security patches. Beta patches: Before releasing a patch to a stable branch, developers may cut a beta release (e.g. v1.2.1b0) for testing.

​
Planning process

​
Quarterly planning meetings

The Flyte team hosts public quarterly planning meetings. These meetings:
  • Review the current state of the platform
  • Prioritize community-submitted ideas and assess interest
  • Decide which items go into the GitHub milestone for the next release
  • Are open to all community members
Look for meeting invites on the Flyte community calendar.

​
Issue lifecycle

  1. Incoming issues are tagged untriaged automatically.
  2. Flyte maintainers triage issues weekly and assign them to milestones.
  3. Once in a milestone, the team is committed to delivering it in that release.
  4. Issues that slip milestones do so only for documented reasons.

​
Change management

To keep changes trackable and explainable:
  • Every PR must be associated with a GitHub issue.
  • Large PRs should be preceded by a design proposal.
  • Every major change must include documentation updates.
  • Owner files (OWNERS) define who reviews what in each repository.

​
Browse features and issues

​
By theme

Bugs

Currently known and open bugs. Open a new one on GitHub.

Enhancements

All new features in development across the platform.

Plugins

New capabilities and execution plugins. Great entry point for contributors.

Scale

Performance, reliability, and scalability improvements.

Security

Security enhancements and CVE fixes.

Good first issues

Best issues to get started contributing to Flyte.

​
By component

Flyte Console (UI)

Issues concerning the web interface.

flytectl (CLI)

Issues concerning the standalone CLI.

Documentation

Documentation gaps, errors, and improvement requests.

​
Live roadmap

For a real-time view of what the Flyte team is working on, see the GitHub Projects board.

​
Recent changes (v1.16.4)

The most recent Flyte release (v1.16.4) included:
  • User annotations support for Kubernetes objects
  • Ray plugin: optional ingress disable flag for Ray clusters
  • Fix for malformed dynamic workflows causing a failed + succeeded + running inconsistent state
  • Fix for panic when retry attempt in map tasks exceeds bit-array allocation
  • Unpinned Kubernetes client library and controller-runtime dependencies for improved compatibility
  • FlyteCTL sandbox: only fetch v1 sandbox images
See the full CHANGELOG for details.

Build docs developers (and LLMs) love

Get started for freeTalk to us