New GA criteria. Rename GA to Stable.

This commit is contained in:
Artur Souza 2021-10-22 14:16:01 -07:00
parent fee4e9840c
commit 0680f429c3
8 changed files with 59 additions and 33 deletions

View File

@ -22,7 +22,7 @@ To make sure a component conforms to the standards set by Dapr, there are a set
The levels are as follows:
- [Alpha](#alpha)
- [Beta](#beta)
- [General availability (GA)](#general-availability-ga)
- [Stable](#stable)
### Alpha
@ -42,11 +42,16 @@ All components start at the Alpha stage.
- The component contains a record of the conformance test result reviewed and approved by Dapr maintainers with specific components-contrib version
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases
### General Availability (GA)
### Stable
- Has at least two different users using the component in production
- A GA component has a maintainer in the Dapr community or the Dapr maintainers
- The component is well documented, tested and maintained across multiple versions of components-contrib repo
- The component must have component [certification tests](#certification-tests) validating functionality and resiliency
- The component is maintained by Dapr maintainers and supported by the community
- The component is well documented and tested
- A maintainer will address component security, core functionality and test issues according to the Dapr support policy and issue a patch release of Dapr that includes the patched stable component
### Previous General Available (GA) components
Any component that was previously certified as GA is now grandfathered into Stable even if the new requirements are not met yet.
## Conformance tests
@ -66,24 +71,45 @@ To understand more about them see the readme [here](https://github.com/dapr/comp
- The tests should validate the functional behavior and robustness of component based on the component specification
- All the details needed to reproduce the tests are added as part of the component conformance test documentation
## Certification tests
Each stable component in the [components-contrib](https://github.com/dapr/components-contrib) repository must have a certification test plan and automated certification tests validating all features supported by the component via Dapr.
Test plan for stable components should include the following scenarios:
- Client reconnection: in case the client library cannot connect to the service for a moment, Dapr sidecar should not require to be restarted once the service is back online.
- Authentication options: validate the component can authenticate with all the supported options.
- Validate resource provisioning: validate if the component automatically provisions resources on initialization, if applicable.
- All scenarios relevant to the corresponding building block and component.
The test plan must be approved by a Dapr maintainer and be published in a `README.md` file along with the component code.
### Test requirements
- The tests should validate the functional behavior and robustness of component based on the component specification, reflecting the scenarios from the test plan
- The tests must run successfully as part of the continuous integration of `components-contrib` repository
## Component certification process
For a component to be certified tests are run in an environment maintained by the Dapr team.
### New component certification: Alpha->Beta or Beta->GA
### New component certification: Alpha->Beta
For a new component requiring a certification change from Alpha to Beta or Beta to GA, a request for component certification follows these steps:
- An issue is created with a request for certification of the component with the current and the new certification levels
- A user of a component submits a PR for integrating the component to run with the defined conformance test suite
- The user details the environment setup in the issue created, so that a Dapr maintainer can setup the service in a managed environment
- After the environment setup is complete, Dapr maintainers review the PR and if approved merges that PR
- Dapr maintainers review functional correctness with the test being run in an environment maintained by the Dapr team
- Dapr maintainers update the component status document categorized by Dapr Runtime version. This is done as part of the release process in the next release of Dapr runtime
### Existing GA certified component
For an existing GA certified component, conformance test should be run against any changes made to component code or the backing service version or the client version.
In the scenarios where a component version is updated, the component again starts from Alpha stage and then the new component certification is followed for that.
For a new component requiring a certification change from Alpha to Beta, a request for component certification follows these steps:
- Requestor creates an issue in `components-contrib` repository for certification of the component with the current and the new certification levels
- Requestor submits a PR for integrating the component to run with the defined conformance test suite, if not included already
- The user details the environment setup in the issue created, so that a Dapr maintainer can setup the service in a managed environment
- After the environment setup is complete, Dapr maintainers review the PR and if approved merges that PR
- Requestor submits a PR in `docs` repository, updating the component's certification level
### New component certification: Beta->Stable
For a new component requiring a certification change from Beta to Stable, a request for component certification follows these steps:
- Requestor creates an issue in `components-contrib` repository for certification of the component with the current and the new certification levels
- Requestor submits a PR for the test plan as a `README.md` file in the component's source code directory
- The user details the test environment requirements in the PR created, including any manual steps or credentials needed
- A Dapr maintainer reviews the test plan, giving feedback or approving it and merge the PR
- Requestor submits a PR for the automated certification tests, including scripts to provision resources when applicable
- After the test environment setup is completed and credentials provisioned, Dapr maintainers review the PR and, if approved, merges the PR
- Requestor submits a PR in `docs` repository, updating the component's certification level

View File

@ -55,7 +55,7 @@ Components are implemented in the components-contrib repository and follow a `MA
The [components-contrib](https://github.com/dapr/components-contrib/) repo release is a flat version across all components inside. That is, a version for the components-contrib repo release is made up of all the schemas for the components inside it. A new version of Dapr does not mean there is a new release of components-contrib if there are no component changes.
Note: Components have a production usage lifecycle status: Alpha, Beta and GA (stable). These statuses are not related to their versioning. The tables of supported components shows both their versions and their status.
Note: Components have a production usage lifecycle status: Alpha, Beta and Stable. These statuses are not related to their versioning. The tables of supported components shows both their versions and their status.
* List of [state store components]({{< ref supported-state-stores.md >}})
* List of [pub/sub components]({{< ref supported-pubsub.md >}})
* List of [secret store components]({{< ref supported-secret-stores.md >}})

View File

@ -28,7 +28,7 @@ Table captions:
| [Apple Push Notifications (APN)]({{< ref apns.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Cron (Scheduler)]({{< ref cron.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [GraphQL]({{< ref graghql.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [HTTP]({{< ref http.md >}}) | | ✅ | GA | v1 | 1.0 |
| [HTTP]({{< ref http.md >}}) | | ✅ | Stable| v1 | 1.0 |
| [InfluxDB]({{< ref influxdb.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Kafka]({{< ref kafka.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Kubernetes Events]({{< ref "kubernetes-binding.md" >}}) | ✅ | | Alpha | v1 | 1.0 |
@ -80,7 +80,7 @@ Table captions:
| [Azure Event Hubs]({{< ref eventhubs.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Azure Service Bus Queues]({{< ref servicebusqueues.md >}}) | ✅ | ✅ | Alpha | v1 | 1.0 |
| [Azure SignalR]({{< ref signalr.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | GA | v1 | 1.0 |
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | Stable| v1 | 1.0 |
### Zeebe (Camunda Cloud)

View File

@ -18,4 +18,4 @@ aliases:
| [OAuth2 client credentials]({{< ref middleware-oauth2clientcredentials.md >}}) | Enables the [OAuth2 Client Credentials Grant flow](https://tools.ietf.org/html/rfc6749#section-4.4) on a Web API | Alpha | v1|
| [Bearer]({{< ref middleware-bearer.md >}}) | Verifies a [Bearer Token](https://tools.ietf.org/html/rfc6750) using [OpenID Connect](https://openid.net/connect/) on a Web API | Alpha | v1|
| [Open Policy Agent]({{< ref middleware-opa.md >}}) | Applies [Rego/OPA Policies](https://www.openpolicyagent.org/) to incoming Dapr HTTP requests | Alpha | v1|
| [Uppercase]({{< ref middleware-uppercase.md >}}) | Converts the body of the request to uppercase letters | GA (For local development) | v1|
| [Uppercase]({{< ref middleware-uppercase.md >}}) | Converts the body of the request to uppercase letters | Stable(For local development) | v1|

View File

@ -21,13 +21,13 @@ The following components provide name resolution for the service invocation buil
| Name | Status | Component version | Since |
|------|:------:|:-----------------:|:-----:|
| [mDNS]({{< ref nr-mdns.md >}}) | GA | v1 | 1.0 |
| [mDNS]({{< ref nr-mdns.md >}}) | Stable| v1 | 1.0 |
### Kubernetes
| Name | Status | Component version | Since |
|------------|:------:|:-----------------:|:-----:|
| [Kubernetes]({{< ref nr-kubernetes.md >}}) | GA | v1 | 1.0 |
| [Kubernetes]({{< ref nr-kubernetes.md >}}) | Stable| v1 | 1.0 |
## Definitions

View File

@ -30,7 +30,7 @@ Table captions:
| [JetStream]({{< ref setup-jetstream.md >}}) | Alpha | v1 | 1.4 |
| [Pulsar]({{< ref setup-pulsar.md >}}) | Alpha | v1 | 1.0 |
| [RabbitMQ]({{< ref setup-rabbitmq.md >}}) | Alpha | v1 | 1.0 |
| [Redis Streams]({{< ref setup-redis-pubsub.md >}}) | GA | v1 | 1.0 |
| [Redis Streams]({{< ref setup-redis-pubsub.md >}}) | Stable | v1 | 1.0 |
### Amazon Web Services (AWS)
@ -49,4 +49,4 @@ Table captions:
| Name | Status | Component version | Since |
|-----------------------------------------------------------|--------| ----------------| -- |
| [Azure Event Hubs]({{< ref setup-azure-eventhubs.md >}}) | Alpha | v1 | 1.0 |
| [Azure Service Bus]({{< ref setup-azure-servicebus.md >}})| GA | v1 | 1.0 |
| [Azure Service Bus]({{< ref setup-azure-servicebus.md >}})| Stable | v1 | 1.0 |

View File

@ -26,7 +26,7 @@ Table captions:
| [Local environment variables]({{< ref envvar-secret-store.md >}}) | Beta | v1 | 1.0 |
| [Local file]({{< ref file-secret-store.md >}}) | Beta | v1 | 1.0 |
| [HashiCorp Vault]({{< ref hashicorp-vault.md >}}) | Alpha | v1 | 1.0 |
| [Kubernetes secrets]({{< ref kubernetes-secret-store.md >}}) | GA | v1 | 1.0 |
| [Kubernetes secrets]({{< ref kubernetes-secret-store.md >}}) | Stable | v1 | 1.0 |
### Amazon Web Services (AWS)
@ -45,4 +45,4 @@ Table captions:
| Name | Status | Component version | Since |
|---------------------------------------------------------------------------------------|--------| ---- |--------------|
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | GA | v1 | 1.0 |
| [Azure Key Vault]({{< ref azure-keyvault.md >}}) | Stable | v1 | 1.0 |

View File

@ -35,10 +35,10 @@ The following stores are supported, at various levels, by the Dapr state managem
| [Hashicorp Consul]({{< ref setup-consul.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
| [Hazelcast]({{< ref setup-hazelcast.md >}}) | ✅ | ❌ | ❌ | ❌ | ❌ | Alpha | v1 | 1.0 |
| [Memcached]({{< ref setup-memcached.md >}}) | ✅ | ❌ | ❌ | ✅ | ❌ | Alpha | v1 | 1.0 |
| [MongoDB]({{< ref setup-mongodb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | GA | v1 | 1.0 |
| [MongoDB]({{< ref setup-mongodb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Stable | v1 | 1.0 |
| [MySQL]({{< ref setup-mysql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
| [PostgreSQL]({{< ref setup-postgresql.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
| [Redis]({{< ref setup-redis.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | GA | v1 | 1.0 |
| [Redis]({{< ref setup-redis.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | Stable | v1 | 1.0 |
| [RethinkDB]({{< ref setup-rethinkdb.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
| [Zookeeper]({{< ref setup-zookeeper.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |
@ -57,7 +57,7 @@ The following stores are supported, at various levels, by the Dapr state managem
| Name | CRUD | Transactional | ETag | [TTL]({{< ref state-store-ttl.md >}}) | [Actors]({{< ref howto-actors.md >}}) | Status | Component version | Since |
|------------------------------------------------------------------|------|---------------------|------|-----|--------|-----|-----|-------|
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | GA | v1 | 1.0 |
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | GA | v1 | 1.0 |
| [Azure Blob Storage]({{< ref setup-azure-blobstorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Stable | v1 | 1.0 |
| [Azure CosmosDB]({{< ref setup-azure-cosmosdb.md >}}) | ✅ | ✅ | ✅ | ✅ | ✅ | Stable | v1 | 1.0 |
| [Azure SQL Server]({{< ref setup-sqlserver.md >}}) | ✅ | ✅ | ✅ | ❌ | ✅ | Alpha | v1 | 1.0 |
| [Azure Table Storage]({{< ref setup-azure-tablestorage.md >}}) | ✅ | ❌ | ✅ | ❌ | ❌ | Alpha | v1 | 1.0 |