Remove Pub/Sub routing from Preview feature list (#2547)

* Remove Pub/Sub routing from Preview feature list

Signed-off-by: crazyhzm <crazyhzm@apache.org>

* remove preview features config

Signed-off-by: crazyhzm <crazyhzm@apache.org>

* Update daprdocs/content/en/operations/support/support-preview-features.md

Co-authored-by: Mark Fussell <markfussell@gmail.com>

daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-route-messages.md

@@ -6,33 +6,12 @@ weight: 2300
 description: "Learn how to route messages from a topic to different event handlers based on CloudEvent fields"
 ---
 
-{{% alert title="Preview feature" color="warning" %}}
-Pub/sub message routing is currently in [preview]({{< ref preview-features.md >}}).
-{{% /alert %}}
-
 Pub/sub routing is an implementation of [content-based routing](https://www.enterpriseintegrationpatterns.com/ContentBasedRouter.html), a messaging pattern that utilizes a DSL instead of imperative application code. With pub/sub routing, you use expressions to route [CloudEvents](https://cloudevents.io) (based on their contents) to different URIs/paths and event handlers in your application. If no route matches, then an optional default route is used. This proves useful as your applications expand to support multiple event versions or special cases.
 
 While routing can be implemented with code, keeping routing rules external from the application can improve portability.
 
 This feature is available to both the [declarative and programmatic subscription approaches]({{< ref subscription-methods.md >}}).
 
-## Enable message routing
-
-To enable this preview feature, add the `PubSub.Routing` feature entry to your application configuration:
-
-```yaml
-apiVersion: dapr.io/v1alpha1
-kind: Configuration
-metadata:
-  name: pubsubroutingconfig
-spec:
-  features:
-    - name: PubSub.Routing
-      enabled: true
-```
-
-Learn more about enabling [preview features]({{< ref preview-features >}}).
-
 ## Declarative subscription
 
 For declarative subscriptions, use `dapr.io/v2alpha1` as the `apiVersion`. Here is an example of `subscriptions.yaml` using routing:

daprdocs/content/en/operations/support/support-preview-features.md

@@ -15,8 +15,7 @@ For CLI there is no explicit opt-in, just the version that this was first made a
 ## Current preview features
 | Feature | Description | Setting | Documentation | Version introduced |
 | ---------- |-------------|---------|---------------|-----------------|
-| **Pub/Sub routing** | Allow the use of expressions to route cloud events to different URIs/paths and event handlers in your application. | `PubSub.Routing` | [How-To: Publish a message and subscribe to a topic]({{<ref howto-route-messages>}}) | v1.4 |
 | **--image-registry** flag with Dapr CLI| In self hosted mode you can set this flag to specify any private registry to pull the container images required to install Dapr| N/A | [init CLI command reference]({{<ref "dapr-init.md#self-hosted-environment" >}}) | v1.7 |
-| **Resiliency** | Allows configuring of fine-grained policies for retries, timeouts and circuitbreaking. | `Resiliency` | [Configure Resiliency Policies]({{<ref "resiliency-overview">}}) | 
+| **Resiliency** | Allows configuring of fine-grained policies for retries, timeouts and circuitbreaking. | `Resiliency` | [Configure Resiliency Policies]({{<ref "resiliency-overview">}}) | v1.7|
 | **Service invocation without default `content-type`** | When enabled removes the default service invocation content-type header value `application/json` when no content-type is provided. This will become the default behavior in release v1.9.0. This requires you to explictly set content-type headers where required for your apps. | `ServiceInvocation.NoDefaultContentType` | [Service Invocation]({{<ref "service_invocation_api.md#request-contents" >}}) | v1.7 |