Updated URLs in docs (#7334)

website/src/docs/hotchocolate/v13/api-reference/apollo-federation.md

@@ -145,7 +145,7 @@ Next, we'll need to define an [entity reference resolver](https://www.apollograp
 
 <Annotation>
 
-In an annotation-based implementation, a reference resolver will work just like a [regular resolver](/docs/hotchocolate/v12/fetching-data/resolvers) with some key differences:
+In an annotation-based implementation, a reference resolver will work just like a [regular resolver](/docs/hotchocolate/v13/fetching-data/resolvers) with some key differences:
 
 1. It must be annotated with the `[ReferenceResolver]` attribute
 1. It must be a `public static` method _within_ the type it is resolving
@@ -208,7 +208,7 @@ public class Product
 
 <Code>
 
-We'll now chain a `ResolveReferenceWith()` method call off of the `Key()` method call from the previous step. This will create a [resolver](/docs/hotchocolate/v12/fetching-data/resolvers) that the Hot Chocolate engine can invoke.
+We'll now chain a `ResolveReferenceWith()` method call off of the `Key()` method call from the previous step. This will create a [resolver](/docs/hotchocolate/v13/fetching-data/resolvers) that the Hot Chocolate engine can invoke.
 
 ```csharp
 public class Product
@@ -282,7 +282,7 @@ public class ProductType : ObjectType<Product>
 
 > ### A note about reference resolvers
 >
-> It's recommended to use a [dataloader](/docs/hotchocolate/v12/fetching-data/dataloader) to fetch the data in a reference resolver. This helps the API avoid [an N+1 problem](https://www.apollographql.com/docs/federation/entities-advanced#handling-the-n1-problem) when a query resolves multiple items from a given subgraph.
+> It's recommended to use a [dataloader](/docs/hotchocolate/v13/fetching-data/dataloader) to fetch the data in a reference resolver. This helps the API avoid [an N+1 problem](https://www.apollographql.com/docs/federation/entities-advanced#handling-the-n1-problem) when a query resolves multiple items from a given subgraph.
 
 ## Register the entity
 
@@ -545,7 +545,7 @@ As a reminder, you can create and configure a supergraph by following either the
 
 ## Contributing fields through resolvers
 
-Now that our new subgraph has the `Product` reference we can [contribute additional fields to the type](https://www.apollographql.com/docs/federation/entities#contributing-entity-fields). Similar to other types in Hot Chocolate, you can create new fields by defining different method or property resolvers. For a full set of details and examples on creating resolvers, you can read our [documentation on resolvers](/docs/hotchocolate/v12/fetching-data/resolvers).
+Now that our new subgraph has the `Product` reference we can [contribute additional fields to the type](https://www.apollographql.com/docs/federation/entities#contributing-entity-fields). Similar to other types in Hot Chocolate, you can create new fields by defining different method or property resolvers. For a full set of details and examples on creating resolvers, you can read our [documentation on resolvers](/docs/hotchocolate/v13/fetching-data/resolvers).
 
 For now, we'll focus on giving our supergraph the ability to retrieve all reviews for a given product by adding a `reviews: [Review!]!` property to the type.
 

website/src/docs/hotchocolate/v14/api-reference/apollo-federation.md

@@ -145,7 +145,7 @@ Next, we'll need to define an [entity reference resolver](https://www.apollograp
 
 <Annotation>
 
-In an annotation-based implementation, a reference resolver will work just like a [regular resolver](/docs/hotchocolate/v12/fetching-data/resolvers) with some key differences:
+In an annotation-based implementation, a reference resolver will work just like a [regular resolver](/docs/hotchocolate/v14/fetching-data/resolvers) with some key differences:
 
 1. It must be annotated with the `[ReferenceResolver]` attribute
 1. It must be a `public static` method _within_ the type it is resolving
@@ -208,7 +208,7 @@ public class Product
 
 <Code>
 
-We'll now chain a `ResolveReferenceWith()` method call off of the `Key()` method call from the previous step. This will create a [resolver](/docs/hotchocolate/v12/fetching-data/resolvers) that the Hot Chocolate engine can invoke.
+We'll now chain a `ResolveReferenceWith()` method call off of the `Key()` method call from the previous step. This will create a [resolver](/docs/hotchocolate/v14/fetching-data/resolvers) that the Hot Chocolate engine can invoke.
 
 ```csharp
 public class Product
@@ -282,7 +282,7 @@ public class ProductType : ObjectType<Product>
 
 > ### A note about reference resolvers
 >
-> It's recommended to use a [dataloader](/docs/hotchocolate/v12/fetching-data/dataloader) to fetch the data in a reference resolver. This helps the API avoid [an N+1 problem](https://www.apollographql.com/docs/federation/entities-advanced#handling-the-n1-problem) when a query resolves multiple items from a given subgraph.
+> It's recommended to use a [dataloader](/docs/hotchocolate/v14/fetching-data/dataloader) to fetch the data in a reference resolver. This helps the API avoid [an N+1 problem](https://www.apollographql.com/docs/federation/entities-advanced#handling-the-n1-problem) when a query resolves multiple items from a given subgraph.
 
 ## Register the entity
 
@@ -545,7 +545,7 @@ As a reminder, you can create and configure a supergraph by following either the
 
 ## Contributing fields through resolvers
 
-Now that our new subgraph has the `Product` reference we can [contribute additional fields to the type](https://www.apollographql.com/docs/federation/entities#contributing-entity-fields). Similar to other types in Hot Chocolate, you can create new fields by defining different method or property resolvers. For a full set of details and examples on creating resolvers, you can read our [documentation on resolvers](/docs/hotchocolate/v12/fetching-data/resolvers).
+Now that our new subgraph has the `Product` reference we can [contribute additional fields to the type](https://www.apollographql.com/docs/federation/entities#contributing-entity-fields). Similar to other types in Hot Chocolate, you can create new fields by defining different method or property resolvers. For a full set of details and examples on creating resolvers, you can read our [documentation on resolvers](/docs/hotchocolate/v14/fetching-data/resolvers).
 
 For now, we'll focus on giving our supergraph the ability to retrieve all reviews for a given product by adding a `reviews: [Review!]!` property to the type.
 

website/src/docs/hotchocolate/v14/api-reference/error-filter.md

@@ -8,7 +8,7 @@ Moreover, you can throw a `QueryException` that will be be caught by the query e
 
 One further way to raise an error are non-terminating field errors. This can be raised by using `IResolverContext.ReportError`. So, with this you can provide a result and raise an error for your current field.
 
-> If you do want to log errors head over to our diagnostic source [documentation](/docs/hotchocolate/v13/server/instrumentation) and see how you can hook up your logging framework of choice to it.
+> If you do want to log errors head over to our diagnostic source [documentation](/docs/hotchocolate/v14/server/instrumentation) and see how you can hook up your logging framework of choice to it.
 
 # Error Builder
 

website/src/docs/hotchocolate/v14/api-reference/extending-filtering.md

@@ -72,7 +72,7 @@ This convention is also configurable with a fluent interface, so in most cases y
 ## Descriptor
 
 Most of the capabilities of the descriptor are already documented under `Fetching Data -> Filtering`.
-If you have not done this already, it is now the right time to head over to [Filtering](/docs/hotchocolate/v13/fetching-data/filtering) and read the parts about the `FilterConventions`
+If you have not done this already, it is now the right time to head over to [Filtering](/docs/hotchocolate/v14/fetching-data/filtering) and read the parts about the `FilterConventions`
 
 There are two things on this descriptor that are not documented in `Fetching Data`:
 
@@ -177,7 +177,7 @@ In case, of MongoDB this is a `FilterDefinition`. Provider, visitor context and
 
 To inspect and analyze the input object, the provider uses a visitor.
 
-What a visitor is and how you can write you own visitor is explained [here](/docs/hotchocolate/v13/api-reference/visitors)
+What a visitor is and how you can write you own visitor is explained [here](/docs/hotchocolate/v14/api-reference/visitors)
 
 Visitors are a powerful yet complex concept, we tried our best to abstract it away.
 For most cases, you will not need to create a custom visitor.

website/src/docs/hotchocolate/v14/defining-a-schema/arguments.md

@@ -117,6 +117,6 @@ services
 </Schema>
 </ExampleTabs>
 
-Arguments can be made required by using the non-null type. Learn more about [non-null](/docs/hotchocolate/v13/defining-a-schema/non-null)
+Arguments can be made required by using the non-null type. Learn more about [non-null](/docs/hotchocolate/v14/defining-a-schema/non-null)
 
-If we need to provide complex objects as arguments, we can use [input object types](/docs/hotchocolate/v13/defining-a-schema/input-object-types).
+If we need to provide complex objects as arguments, we can use [input object types](/docs/hotchocolate/v14/defining-a-schema/input-object-types).

website/src/docs/hotchocolate/v14/defining-a-schema/enums.md

@@ -2,7 +2,7 @@
 title: "Enums"
 ---
 
-An Enum is a special kind of [scalar](/docs/hotchocolate/v13/defining-a-schema/scalars) that is restricted to a particular set of allowed values. It can be used as both an input and an output type.
+An Enum is a special kind of [scalar](/docs/hotchocolate/v14/defining-a-schema/scalars) that is restricted to a particular set of allowed values. It can be used as both an input and an output type.
 
 ```sdl
 enum UserRole {
@@ -137,7 +137,7 @@ Since there could be multiple enum types inheriting from `EnumType<UserRole>`, b
 
 **Therefore it's important to note that Code-first enum types are not automatically inferred. They need to be explicitly specified or registered.**
 
-We can either [explicitly specify the type on a per-resolver basis](/docs/hotchocolate/v13/defining-a-schema/object-types#explicit-types) or we can register the type once globally:
+We can either [explicitly specify the type on a per-resolver basis](/docs/hotchocolate/v14/defining-a-schema/object-types#explicit-types) or we can register the type once globally:
 
 ```csharp
 public class Startup

website/src/docs/hotchocolate/v14/defining-a-schema/index.md

@@ -8,77 +8,77 @@ In this section we will learn everything that is needed to build an expressive G
 
 First we will look at the three root types, often called _Operations_, that represent entry points to our schema:
 
-- Queries allow us to _query_ our graph and retrieve data in a readonly manner.<br />[Learn more about queries](/docs/hotchocolate/v13/defining-a-schema/queries)
+- Queries allow us to _query_ our graph and retrieve data in a readonly manner.<br />[Learn more about queries](/docs/hotchocolate/v14/defining-a-schema/queries)
 
-- Mutations allow us to _mutate_ our graph entities in the form of adding, removing or updating entities.<br />[Learn more about mutations](/docs/hotchocolate/v13/defining-a-schema/mutations)
+- Mutations allow us to _mutate_ our graph entities in the form of adding, removing or updating entities.<br />[Learn more about mutations](/docs/hotchocolate/v14/defining-a-schema/mutations)
 
-- Subscriptions allow us to _subscribe_ to events in our system and be notified in real-time of their occurrence.<br />[Learn more about subscriptions](/docs/hotchocolate/v13/defining-a-schema/subscriptions)
+- Subscriptions allow us to _subscribe_ to events in our system and be notified in real-time of their occurrence.<br />[Learn more about subscriptions](/docs/hotchocolate/v14/defining-a-schema/subscriptions)
 
 # Types
 
 Each GraphQL schema is made up of two basic building blocks:
 
-- Object types contain fields and describe our entities.<br />[Learn more about object types](/docs/hotchocolate/v13/defining-a-schema/object-types)
+- Object types contain fields and describe our entities.<br />[Learn more about object types](/docs/hotchocolate/v14/defining-a-schema/object-types)
 
-- Scalars are the primitives of our GraphQL schema: `String`, `Int`, etc.<br />We can also define custom scalars to more precisely describe our business domain.<br />[Learn more about scalars](/docs/hotchocolate/v13/defining-a-schema/scalars)
+- Scalars are the primitives of our GraphQL schema: `String`, `Int`, etc.<br />We can also define custom scalars to more precisely describe our business domain.<br />[Learn more about scalars](/docs/hotchocolate/v14/defining-a-schema/scalars)
 
 There are also more advanced types:
 
-- Enums are a special kind of scalar, restricted to a particular set of allowed values.<br />[Learn more about enums](/docs/hotchocolate/v13/defining-a-schema/enums)
-- Interfaces represent a shared contract that other types can implement.<br />[Learn more about interfaces](/docs/hotchocolate/v13/defining-a-schema/interfaces)
-- Unions represent a set of object types, without the need for a shared contract.<br />[Learn more about unions](/docs/hotchocolate/v13/defining-a-schema/unions).
+- Enums are a special kind of scalar, restricted to a particular set of allowed values.<br />[Learn more about enums](/docs/hotchocolate/v14/defining-a-schema/enums)
+- Interfaces represent a shared contract that other types can implement.<br />[Learn more about interfaces](/docs/hotchocolate/v14/defining-a-schema/interfaces)
+- Unions represent a set of object types, without the need for a shared contract.<br />[Learn more about unions](/docs/hotchocolate/v14/defining-a-schema/unions).
 
 # Type Modifiers
 
 Besides regular types, like scalars and object types, there are also _type modifiers_.
 
 A non-null field for example indicates that a client can always expect a non-null value to be returned from the field.
 
-[Learn more about non-null](/docs/hotchocolate/v13/defining-a-schema/non-null)
+[Learn more about non-null](/docs/hotchocolate/v14/defining-a-schema/non-null)
 
 List fields indicate to a client that the field will return a list in the specified shape.
 
-[Learn more about lists](/docs/hotchocolate/v13/defining-a-schema/lists)
+[Learn more about lists](/docs/hotchocolate/v14/defining-a-schema/lists)
 
 # Arguments
 
 We can pass arguments to individual fields on an object type and access their values inside the field's resolver.
 
-[Learn more about arguments](/docs/hotchocolate/v13/defining-a-schema/arguments)
+[Learn more about arguments](/docs/hotchocolate/v14/defining-a-schema/arguments)
 
 Nested object types can also be used as arguments by declaring so called input object types. These are most commonly used when passing a payload to a mutation.
 
-[Learn more about input object types](/docs/hotchocolate/v13/defining-a-schema/input-object-types)
+[Learn more about input object types](/docs/hotchocolate/v14/defining-a-schema/input-object-types)
 
 # Extending Types
 
 Hot Chocolate allows us to extend existing types, helping us keep our code organized.
 
 Rather than adding more and more fields to the Query type in the same class for instance, we can _extend_ the Query type with a new field from another location in our codebase where that field logically should live.
 
-[Learn more about extending types](/docs/hotchocolate/v13/defining-a-schema/extending-types)
+[Learn more about extending types](/docs/hotchocolate/v14/defining-a-schema/extending-types)
 
 # Directives
 
 Directives allow us to decorate parts of our GraphQL schema with additional configuration.
 
 This configuration can be used as metadata for client tools or alternate our GraphQL server's runtime execution and type validation behavior.
 
-[Learn more about directives](/docs/hotchocolate/v13/defining-a-schema/directives)
+[Learn more about directives](/docs/hotchocolate/v14/defining-a-schema/directives)
 
 # Schema evolution
 
 As our data graph and number of developers/clients grows, we need to ensure that the graph is understood by everyone. Therefore, our schema should expose as much information to consumers of our API as possible.
 
-[Learn more about schema documentation](/docs/hotchocolate/v13/defining-a-schema/documentation)
+[Learn more about schema documentation](/docs/hotchocolate/v14/defining-a-schema/documentation)
 
-[Learn more about versioning](/docs/hotchocolate/v13/defining-a-schema/versioning)
+[Learn more about versioning](/docs/hotchocolate/v14/defining-a-schema/versioning)
 
 # Relay
 
 [Relay](https://relay.dev) proposes some schema design principles for GraphQL servers in order to more efficiently fetch, refetch and cache entities on the client. Since these principles make for a better schema, we encourage all users, not only those of Relay, to consider these principles.
 
-[Learn more about Relay-compatible schema design](/docs/hotchocolate/v13/defining-a-schema/relay)
+[Learn more about Relay-compatible schema design](/docs/hotchocolate/v14/defining-a-schema/relay)
 
 # Automatic type registration
 

website/src/docs/hotchocolate/v14/defining-a-schema/input-object-types.md

@@ -2,9 +2,9 @@
 title: "Input Object Types"
 ---
 
-We already looked at [arguments](/docs/hotchocolate/v13/defining-a-schema/arguments), which allow us to use simple [scalars](/docs/hotchocolate/v13/defining-a-schema/scalars) like `String` to pass data into a field. GraphQL defines input object types to allow us to use objects as arguments on our fields.
+We already looked at [arguments](/docs/hotchocolate/v14/defining-a-schema/arguments), which allow us to use simple [scalars](/docs/hotchocolate/v14/defining-a-schema/scalars) like `String` to pass data into a field. GraphQL defines input object types to allow us to use objects as arguments on our fields.
 
-Input object type definitions differ from [object types](/docs/hotchocolate/v13/defining-a-schema/object-types) only in the used keyword and in that their fields can not have arguments.
+Input object type definitions differ from [object types](/docs/hotchocolate/v14/defining-a-schema/object-types) only in the used keyword and in that their fields can not have arguments.
 
 ```sdl
 input BookInput {
@@ -119,7 +119,7 @@ public class MutationType : ObjectType
 
 The `IInputTypeDescriptor` is really similar to the `IObjectTypeDescriptor` and provides almost the same capabilities.
 
-[Learn more about object types](/docs/hotchocolate/v13/defining-a-schema/object-types)
+[Learn more about object types](/docs/hotchocolate/v14/defining-a-schema/object-types)
 
 </Code>
 <Schema>

website/src/docs/hotchocolate/v14/defining-a-schema/mutations.md

@@ -137,11 +137,11 @@ public class Startup
 
 > Warning: Only **one** mutation type can be registered using `AddMutationType()`. If we want to split up our mutation type into multiple classes, we can do so using type extensions.
 >
-> [Learn more about extending types](/docs/hotchocolate/v13/defining-a-schema/extending-types)
+> [Learn more about extending types](/docs/hotchocolate/v14/defining-a-schema/extending-types)
 
 A mutation type is just a regular object type, so everything that applies to an object type also applies to the mutation type (this is true for all root types).
 
-[Learn more about object types](/docs/hotchocolate/v13/defining-a-schema/object-types)
+[Learn more about object types](/docs/hotchocolate/v14/defining-a-schema/object-types)
 
 # Transactions
 

website/src/docs/hotchocolate/v14/defining-a-schema/object-types.md

@@ -405,11 +405,11 @@ public class Startup
 
 What we have just created is a resolver. Hot Chocolate automatically creates resolvers for our properties, but we can also define them ourselves.
 
-[Learn more about resolvers](/docs/hotchocolate/v13/fetching-data/resolvers)
+[Learn more about resolvers](/docs/hotchocolate/v14/fetching-data/resolvers)
 
 # Generics
 
-> Note: Read about [interfaces](/docs/hotchocolate/v13/defining-a-schema/interfaces) and [unions](/docs/hotchocolate/v13/defining-a-schema/unions) before resorting to generic object types.
+> Note: Read about [interfaces](/docs/hotchocolate/v14/defining-a-schema/interfaces) and [unions](/docs/hotchocolate/v14/defining-a-schema/unions) before resorting to generic object types.
 
 In the Code-first approach we can define generic object types.