Knative Migration-To-Core Process

This document provides a maturity model for projects in the Knative community. This includes projects in knative-sandbox (broader community) or as well as projects in other GitHub organizations which wish to participate in the community process. It also defines a process for migrating community projects into the Knative core, if appropriate. Note that projects may not map 1:1 with repos, and projects may even be hierarchical (for example, the “eventing” project includes “eventing API”, “eventing delivery” and “eventing sources”, each of which has artifacts in multiple repositories).

Note that this document intentionally refers to the process of selecting implemented interfaces from sandbox which should be part of core as “migration-to-core” rather than “incubation” or “promotion” – while it may be personally satisfying to have a component be part of the core, components which are not in the core may be equally valuable and production-worthy.

Maturity phases


In the initiating phase, a project is starting up, and may have minimal additional artifacts around the code itself. The minimum bar for an initiating project in the knative-sandbox org is:

Projects which do not declare otherwise are assumed to be in the “Initiating” phase, regardless of release process, users, etc.

This phase is suitable for:

Note that Initiating projects do not need to be hosted in knative-sandbox, and can be hosted under either individual accounts or in other orgs. For projects in knative-sandbox, review requirements and cadence are at the discretion of the sponsoring WG lead.


A usable project has reached the point where it is releasing executable artifacts which are in use by at least two end users (preferably different companies, rather than installations within the same company). Additionally, a usable project meets certain other criteria (defined below) which allows the Knative community to have confidence in the project and willingness to invest further.

Additional requirements beyond “initiating”:

Usable projects which meet the criteria for core (i.e. developer-facing abstractions with wide utility, beta+ APIs) may apply to the TOC and SC for migration to core, but approval is more likely for projects in the “Stable” category.


A stable project has graduated beyond the bar in “usable” and is widely-adopted with a stable API and well-understood operational characteristics. This would be similar to a “GA” level of support for a commercial product in terms of maturity.

Additional requirements beyond “usable”:

Projects are generally encouraged to reach stable maturity before considering migration to core.


At any time, a project may move into the “sunsetting” phase. This is a declaration that the project will no longer managed or maintained. For a project which is currently in the “stable” phase, there should be a clear commitment to support the project with bug and security fixes as applicable based on the Knative release principles (4 versions of Knative).

Migration to Core

A stable project may apply to the SC and TOC to be admitted to the Knative core. Not all stable projects are suitable for “core”; this is a judgement as to the degree to which the project should be considered a part of a “expected developer experience” across Knative installations. Projects may be graded on the following criteria (to be updated based on experience):