Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated. # Releases ## @apollo/composition@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](b18841b), [`e325b499`](e325b49)]: - @apollo/query-graphs@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/gateway@2.6.0 ### Minor Changes - Add more information to OpenTelemetry spans. ([#2700](#2700)) Rename `operationName` to `graphql.operation.name` and add a `graphql.operation.type` attribute, in conformance with the OpenTelemetry Semantic Conventions for GraphQL. The `operationName` attribute is now deprecated, but it is still emitted alongside `graphql.operation.name`. Add a `graphql.document` span attribute to the `gateway.request` span, containing the entire GraphQL source sent in the request. This feature is disable by default. When one or more GraphQL or internal errors occur, report them in the OpenTelemetry span in which they took place, as an exception event. This feature is disabled by default. To enable the `graphql.document` span attribute and the exception event reporting, add the following entries to your `ApolloGateway` instance configuration: ```ts const gateway = new ApolloGateway({ // ... telemetry: { // Set to `true` to include the `graphql.document` attribute includeDocument: true, // Set to `true` to report all exception events, or set to a number // to report at most that number of exception events per span reportExceptions: true, // or: reportExceptions: 1 }, }); ``` - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` - Add graphql.operation.name attribute on gateway.plan span ([#2807](#2807)) ### Patch Changes - Updated dependencies \[[`b18841be`](b18841b), [`e325b499`](e325b49)]: - @apollo/query-planner@2.6.0 - @apollo/composition@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/federation-internals@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ## @apollo/query-graphs@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](b18841b), [`e325b499`](e325b49)]: - @apollo/federation-internals@2.6.0 ## @apollo/query-planner@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](b18841b), [`e325b499`](e325b49)]: - @apollo/query-graphs@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/subgraph@2.6.0 ### Patch Changes - Updated dependencies \[[`b18841be`](b18841b), [`e325b499`](e325b49)]: - @apollo/federation-internals@2.6.0 ## apollo-federation-integration-testsuite@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([#2741](#2741)) - Introduce the new `@policy` scope for composition ([#2818](#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
- Loading branch information
1 parent
cd00b17
commit b6bcfd8