6.3.0

This is a minor update, which includes some routing improvements.

Features

All Platforms

• ApiVersioningOptions.UnsupportedApiVersionStatusCode has been added to indicate the status code used when an API version doesn't match
  • The default value is 400, which has been the de facto from the beginning
  • Any status code can be used, but 400, 404, or 501 are generally the ones that make sense
  • Each response will continue to include ProblemDetails, which is always the same; regardless of status code
  • When versioning exclusively by URL segment or the incoming request URL is determined to yield an API version route parameter, this option is ignored and the response will always be 404
• A Sunset Policy will always attempt be written when reporting API versions
  • Previously, it was only written on success because success is required for API-specific policies
  • A version-specific policy can be written even during failure since it is related to the version as a whole, regardless of API

Fixes

ASP.NET Core

• IApiVersioningBuilder.AddMvc and IApiVersioningBuilder.AddApiExplorer now ensure dependent services are registered
  • AddApiExplorer, in particular, snagged a number of people that didn't realize they needed AddMvc
• The ProblemDetails.Code extension is now correctly written in JSON as code
• API versions are now reported when an endpoint is unmatched (#876, #918)
  • This should restore the behavior for unmatched endpoints that existed prior to 6.0
  • This is a best effort
    • No erroneous scenarios have been found, but there could be edge cases
    • The behavior is relying on the routing system to collate the metadata from endpoints that are already collated by name using their route templates
    • Attempts to create contrived configurations that could yield incorrect results were unsuccessful (which is good)

Breaking Changes

Restoring the unmatched endpoint behavior may break the expectations for those that have adopted 6.0. There's no good answer or time for this change to occur since this is an implementation detail that only manifests in behavior. Despite calling out the changes in the roadmap and release notes, several issues have been filed related to the change in 6.0. At the time, it didn't seem possible to retain that functionality, but it seems that - largely - it can be.

Ultimately, this change only affects APIs that are strictly concerned about whether the response will be 400 or 404 for client errors on unmatched versions. 400 will now revert to be the default case where you might have received 404. If it's important to you to retain the behaviors you've established while adopting 6.x, you can achieve that by setting:

ASP.NET Web API

(ApiVersioningOptions options) => options.UnsupportedApiVersionStatusCode = HttpStatusCode.NotFound

ASP.NET Core

(ApiVersioningOptions options) => options.UnsupportedApiVersionStatusCode = 404

Special note for .NET Core 3.1 users. There are edge cases where 404 is returned instead of 400. In reviewing the test cases, this was already a problem. It's unclear why that happens, but it appears to be a change or fix in the routing system in at least .NET 6.0 and above. This will be considered the expected behavior. It may be possible to change the behavior with middleware.

7.0.0 Preview 2

This is the second and likely final preview release for ASP.NET Core with .NET 7.0 support. No additional work is planned, but there are some breaking changes that can be tried, tested, and discussed before promoting to the official release.

Features

ASP.NET Core

• Added MapApiGroup() as a shortcut for MapGroup( "" ).WithApiVersionSet()
• Metadata can now be added to groups (e.g. RouteGroupBuilder)
• Added injectable VersionedEndpointRouteBuilderFactory delegate

In Preview 2, metadata can now be applied even more succinctly.

var builder = WebApplication.CreateBuilder( args );

builder.Services.AddApiVersioning();

var app = builder.Build();
var orders = app.MapApiGroup();                                  // ← api group with optional name
var v1 = orders.MapGroup(  "/api/order"  ).HasApiVersion( 1.0 ); // ← all endpoints in this group have 1.0
var v2 = orders.MapGroup(  "/api/order"  ).HasApiVersion( 2.0 ); // ← all endpoints in this group have 2.0

v1.MapGet( "/{id:int}", ( int id ) => new V1.Order() { Id = id, Customer = "John Doe" } );
v2.MapGet( "/{id:int}", ( int id ) => new V2.Order() { Id = id, Customer = "John Doe", Phone = "555-555-5555" } );
v2.MapDelete( "/{id:int}", ( int id ) => Results.NoContent() );

All of the previous methods of configuring metadata are still supported. For more examples, refer to the:

• Minimal API Example
• Minimal OpenAPI Example

Fixes

• Use 404 over 400 when versioning only by URL segment (#911)

Breaking Changes

The following are breaking changes from Preview 1. If you haven't added any customizations, these should all be source code compatible.

• Add group metadata validation to avoid common developer mistakes
• Replace IApiVersionSetBuilderFactory interface with injectable ApiVersionSetBuilderFactory delegate
• Refactor RouteHandlerBuidler extensions into IEndpointRouteBuilderExtensions
  • This allows adding metadata on an endpoint or route group

If you have additional input or feedback, please provide them in the discussion. This will likely be the last time to discuss it before the release becomes official.

7.0.0 Preview 1

This is the first preview release for ASP.NET Core with .NET 7.0 support. No additional work is planned, but there are some breaking changes that can be tried, tested, and discussed before promoting to the official release.

Features

ASP.NET Core

• Migrate from IProblemDetailsFactory to IProblemDetails
• Adding grouping support for MapGroup in Minimal APIs

Versioning Minimal APIs still requires a version set which collates configured API versions, but the new MapGroup support makes the setup more natural.

var builder = WebApplication.CreateBuilder( args );

builder.Services.AddApiVersioning();

var app = builder.Build();
var orders = app.MapGroup( "/api/order" ).WithApiVersionSet();

orders.MapGet( "/{id:int}", ( int id ) => new Order() { Id = id, Customer = "John Doe" } ).HasApiVersion( 1.0 );

ASP.NET Core with OData

• OData does not officially support .NET 7, but it is compatible
  • It is assumed that the eventual support will continue to be forward compatible or bump to 9.0
  • A breaking change in 9.0 could cause complication or require a major version bump for OData packages here

Breaking Changes

• As previously announced, .NET Core 3.1 has been dropped and is end of life in December 2022
• Minimal APIs implementation:
  • IVersionedEndpointConventionBuilder and VersionedEndpointConventionBuilder have been removed and are no longer necessary
  • DefaultApiVersionSetBuilderFactory now has a parameterless, default constructor
  • IVersionedEndpointConventionBuilder WithApiVersionSet(IEndpointConventionBuilder, ApiVersionSet) is now TBuilder WithApiVersionSet<TBuilder>(TBuilder, ApiVersionSet) where TBuilder : notnull, IEndpointConventionBuilder
• ProblemDetails implementation
  • IProblemDetailsFactory has been removed and is supplanted by the built-in IProblemDetailsService
  • The built-in IServiceCollection.AddProblemDetails() must be called to add ProblemDetails
    • This puts the control in your hands
    • Can result in a behavioral breaking change if you omit the setup

If you have additional input or feedback, please provide them in the discussion. This will be the one and only time to discuss it before the release becomes official.

6.2.0

This is a minor release which contains mostly fixes and a few new enhancements. The next phase in the roadmap will be supporting .NET 7.0.

.NET Core 3.1 will be End of Life in December of 2022; therefore, support for that target framework will be dropped in the next major release. With the exception of servicing for bug fixes, this will be the last release for .NET Core 3.1.

Features

Abstractions

• Added ApiVersionMetadata copy constructor

All Platforms

• Add complex media type API version reader support (#887)

ASP.NET Web API

• Type-forward route parsing from API Explorer to core library

ASP.NET Web API with OData

• Add support for exploring OData metadata routes (#893)

ASP.NET Core

• Support 406 and 415 with ProblemDetails (#886)
• Handle missing ApiVersionMetadata (#891)
• Handle multiple SelectorModel instances (#896)
• Add IApiVersionDescriptionProviderFactory (enables DI within DescribeApiVersions)
• Add support for custom group name formatting

ASP.NET Core with OData

• Add support for exploring OData metadata routes (#893)

New Feature Preview

Enhanced Media Type Reader

The new MediaTypeApiVersionReaderBuilder has compositional support with the following features:

• Multiple parameters (if they vary by media type)
• Including specific media types
• Excluding specific media types
• Matching a version in a media type by regular expression (it's an escape hatch really)
• Matching a version in a media type by a template
• Disambiguate from multiple choices

Here's a basic example:

var builder = new MediaTypeApiVersionReaderBuilder()
var reader = builder
    .Parameter( "v" )
    .Include( "application/json" )
    .Include( "application/xml" )
    .Template( "application/vnd-v{ver}+json" )
    .Template( "application/vnd-v{ver}+xml" )
    .Build();

This will match:

• A parameter named v on any media type filtered to:
  • application/json
  • application/xml
• A media type matching the template application/vnd-v{ver}+json where ver is the user-defined parameter name
• A media type matching the template application/vnd-v{ver}+xml where ver is the user-defined parameter name

Composite Group Names

The API Explorer and OpenAPI (aka Swagger) UI do not support multi-level grouping. Implementing some form of this
has been possible, but complex in the past. API Versioning uses a formatted API version as the group name as a
logical choice, but some people want to combine that with a group name. A new feature will give you the option
to format a group name and API version together.

services.AddApiVersioning()
        .AddApiExplorer( options =>
        {
          options.GroupNameFormat = "'v'VVV";
          options.FormatGroupName = (groupName, apiVersion) => $"{groupName}-{apiVersion}";
        });

There are multiple ways to define a group name, but a controller might look like:

[ApiVersion( 1.0 )]
[ApiController]
[ApiExplorerSettings( GroupName = "Example" )]
[Route( "[controller]" )]
public class ExampleController : ControllerBase
{
  [HttpGet]
  public IActionResult Get() => Ok();
}

The formatting rules are as follows:

• ApiVersion.ToString( ApiExplorerOptions.GroupNameFormat ) is the default group name
• If a group name is defined and ApiExplorerOptions.FormatGroupName is null, the group name is used
• If a group name is defined and ApiExplorerOptions.FormatGroupName is not null, the callback is invoked with the group name and formatted API version
• If a group name is not defined, then the formatted API version is used

In the example above, the final group name will become Example-v1.

OData Metadata Endpoints

OData has a built-in Service Document and Metadata endpoint. These largely serve the same purpose as OpenAPI (aka Swagger) in
days gone by. You might, however, still want these to show up. The default will continue to keep them hidden, but you can now enable
showing one or both of them via:

services.AddControllers().AddOData();

services.AddApiVersioning()
        .AddOData( options => options.AddRouteComponents() )
        .AddODataApiExplorer( options.MetadataOptions = ODataMetadataOptions.All );

Breaking Changes

No known breaking changes

Contributors

Thanks you to all that contributed directly with code, filling issues, and in-depth discussions. In particular, special thanks to:

• @mlunelli (#889, #891)
• @gimlichael (#886, #887)
• @Angelinsky7 (#893)
• @orryverducci (#896)
• @brandonsmith86 (#899)

6.1.0

This is a minor release which contains mostly fixes and a few minor enhancements. The next phase in the roadmap will be supporting .NET 7.0.

.NET Core 3.1 will be End of Life in December of 2022; therefore, support for that target framework will be dropped in the next major release.

Features

All Platforms

• ApiVersion now has a protected copy constructor
• Support custom reporting HTTP headers (#875)

ASP.NET Web API with OData

• Update OData query option exploration (#702, #853)

ASP.NET Core

• ApiVersion can be bound in Minimal APIs using the new EnableApiVersionBinding() extension method for IApiVersioningBuilder
• Fix matching precedence of overlapping endpoint templates (#884)

ASP.NET Core with OData

• Support batching (#720, #847)
• Update OData query option exploration (#702, #853)

Client Extensions

• Support reading custom HTTP headers (#875)

Breaking Changes

No known breaking changes

6.0.0

This is the official 6.0.0 release with support for .NET 6.0 and OData 8.0.

📣 Note that the new package names are Asp.Versioning.*. For more background, see the announcement and roadmap.

Features

No significant new features from the previous pre-releases.

Fixes

ASP.NET Web API with OData

• Support cast routing convention (#738)
• Use assembly-qualified type names for EDM type resolution (#854)

ASP.NET Core

• Clone IsDefaultResponse for API Explorer (#823)
• Provide workaround for ASP.NET Core bug dotnet/aspnetcore#41773 (#830)
• Avoid NullReferenceException when reporting API version for non 2xx (#837)
• Skip collation of actions without versioning metadata (#839)

ASP.NET Core with OData

• Support cast routing convention (#738)
• Revert to 8.0.2 as baseline OData version (#836)
• Fix normalization of OData endpoint metadata (#850)
• Use assembly-qualified type names for EDM type resolution (#854)

Breaking Changes

No known breaking changes

Contributors

Big thank you to the community for helping burn-in the pre-releases, sharing your thoughts, and reporting issues, but especially:

• @icnocop - fixed #738
• @ChrisSfanos - whiteglove service onboarding to .NET Foundation
• @clairernovotny - removing roadblocks in packaging and publishing

5.1.0

This represents the official release for ASP.NET Core with support for .NET 5.0 and .NET 6.0.

📣 Aside from servicing, 5.1.x marks the end of the packages and naming under the Microsoft.AspNet* prefixes. For more background, see the announcement and roadmap. Despite months of communicate with Microsoft and the .NET Foundation to re-enable publishing permissions for the NuGet packages, I'm still unable to. At this point, I suspect it may never happen and this release contains the official, signed packages which you can integrate into your own NuGet feeds.

This release has been a long time coming, but has been stymied due to administrative changes in moving the project under the .NET Foundation. Now that the process is complete, you can expect fluid releases once more. The following highlights high-level changes since 5.0.0. For the complete list, please review the change log.

Features

No significant new features in this release

Fixes

All Platforms

• Fix deprecated API version aggregation (#719)
• Fix API version parsing from namespace (#805)

ASP.NET Web API

• Avoid LockRecursionException (#703)

ASP.NET Web API with OData

• Fix route template building optimizations (#689, #710)
• Correct binding source for [FromODataUri] (#693, #729, #737)
• Disambiguate OData actions by parameters (#697)
• Support cast routing convention (#738)
• Handle PostTo navigation properties (#742)
• Fix all functions versus all function (#758)
• Use assembly-qualified type names for EDM type resolution (#854)

ASP.NET Core

• Handle on-demand initialization of IApiVersioningFeature (#704)
• Clear IApiVersioningFeature on pipeline reentry (#748, #749)
• Limit Allow for 405 to actions in the same API version (#795)
• Handle candidates that differ by route constraint only (#797)

ASP.NET Core with OData

• Fix route template building optimizations (#689, #710)
• Correct binding source for [FromODataUri] (#693, #729, #737)
• Handle DI service registration order (#694)
• Copy endpoint metadata (#695)
• Disambiguate OData actions by parameters (#697)
• Support cast routing convention (#738)
• Handle PostTo navigation properties (#742)
• IEdmModelSelector leverages IApiVersionSelector (#745)
• Fix all functions versus all function (#758)
• Use assembly-qualified type names for EDM type resolution (#854)

Enhancements

All Platforms

• Added IControllerNameConvention (#734)
• Do not discover API versions which are only mapped (#735)
• Update build status badge (#775)

ASP.NET Web API

• Minor optimization to IUrlFactory implementation (#720)

ASP.NET Core

• Report API versions for ambiguous request in legacy routing
• Add support for .NET 6.0

Breaking Changes

No known breaking changes

Additional Release Notes

ASP.NET Core with OData

• The official OData release is now 8.x, but due to the required changes this release targets 7.x with .NET Core 3.1
• The 6.0 support for OData has been rebuilt from the ground up and supports 8.x along with .NET Core 3.1 and .NET 6.0

Contributors

Big thank you to the community for contributing:

• @xavierjohn - new examples
• @aleks-ivanov - fix/improve build and code analysis
• @GrayPockets - Allow ICollectionModelBinder as registered parameters
• @icnocop - fixed #738

6.0.0 Preview 3

This iteration contains a few minor enhancements, bug fixes, and a significant refactoring of the Minimal API support.

Enhancements

All Platforms

• ApiVersion now has a protected constructor parameter that accepts a custom status validation function

ASP.NET Core

• Added target for .NET Core 3.1 TFM (#815)
  • Expect this to be dropped in 7.0 per the .NET Core 3.1 End of Support policy

ASP.NET Core with OData

• API Explorer extensions now support OData query options for non-OData controllers
• Added example to demonstrate OData query options for non-OData controllers

ASP.NET Web API with OData

• API Explorer extensions now support OData query options for non-OData controllers
• Added example to demonstrate OData query options for non-OData controllers

Fixes

ASP.NET Core with OData

• Fix mapping of API version metadata to OData endpoints
• Fix/verify OData OpenAPI example (#821 #825)

Breaking Changes

After a lengthy discussion with @davidfowl himself (#751), Minimal API support has been significantly refactored. The end result is less than what I had hoped for the API to look like, but much more inline with you should expect and with far less duplicated code. ASP.NET Core 6.0 has no grouping construct so it doesn't really make sense to shoehorn it in. A grouping concept will be introduced in 7.0 at which time API Versioning will likely provide new extensions that make composing API version sets more succinct.

The current Minimal API design is primarily meant to attach metadata, not extend the builder. API Versioning needs/wants both, which is why it had its own grouping mechanism. That didn't come without consequence. To work within the current design limitations, an API version set is built outside of any Minimal API. This isn't the policy nor complete metadata. This is the version set that you might have otherwise included in a grouping. The WithApiVersionSet extension method will create and return a new IVersionedEndpointConventionBuilder that is a composition between IEndpointConventionBuilder and IMapToApiVersionConventionBuilder. This allows the existing, intrinsic extension methods to continue working as they always have, but allow you to continue building API version related metadata. The ApiVersionMetadata for the configured Endpoint isn't constructed until just before the Endpoint itself is constructed.

For example:

builder.Services.AddApiVersioning();

var app = builder.Build();

// define a 'version set' that applies to an API group
var versionSet = app.NewApiVersionSet()
                    .HasApiVersion(1.0)
                    .HasApiVersion(2.0)
                    .ReportApiVersions()
                    .Build();

app.MapGet("/values/{id}", (string id) => $"Value {id} (V1)")
   .WithApiVersionSet(versionSet)
   .MapToApiVersion(1.0);

app.MapGet("/values/{id}", (int id) => $"Value {id} (V2)")
   .WithApiVersionSet(versionSet)
   .MapToApiVersion(2.0);

This change solves other issues caused by duplicating or reimplementing some of the built-in behaviors such #823 and #824.

Apologies for the change in direction, but I think this is the right way to go given all the feedback. Some level of feedback was necessary to dial things in and I want to thank everyone that has been trying out the previews and/or commenting on the initial design. Save any other bugs or limitations yet to be uncovered, I believe the design for 6.0 is now stable. I don't expect, nor have planned, any other changes for Minimal APIs. I'm still listening to your feedback, so feel free to comment or suggest other changes. A few people have looked that the changes in the last PR branch and are pleased with the changes, despite the shift in direction.

6.0.0 Preview 2

This is a quick iteration to Preview 2 with a few key fixes and enhancements.

Enhancements

All Platforms

• Added ApiExplorerOptions.RouteConstraintName (useful for resolving API parameters by constraint)

ASP.NET Core

• Added DescribeApiVersions extension method which can be used by WebApplication
  • This is functionally equivalent to IApiVersionDescriptionProvider
  • The implementation uses the DefaultApiVersionDescriptionProvider
• DefaultApiVersionDescriptionProvider now uses EndpointDataSource instead of IActionDescriptorCollectionProvider
• ApiVersionMetadata.Name will be used for controller token in ActionDescriptor for Minimal APIs, if specified
  • For Minimal APIs, this is typically provided via app.DefineApi(name: "My API")
• Added feature parity with OpenApiRouteHandlerExtensions such as Accepts, Produces, etc
  • Note: This might change in the future. See dotnet/aspnetcore#39604
• Added OpenAPI example with API Versioning, Minimal APIs, and Swashbuckle

Fixes

ASP.NET Core

• Support API Explorer extensions for Minimal APIs (#812)

6.0.0 Preview 1

This is the first preview release, which includes support for .NET 6.0. Be sure to follow the announcement for more background and the roadmap for in-depth review of the release.

The wiki has not been updated, but it's a work in progress. While the wiki has been useful and informative, it is reaching the limits of what is possible. Consideration is being made to lift the current wiki into a fully-fledged documentation website. All of the examples have been updated and include new examples such as Minimal APIs. This is currently the best place to start and review how things have changed.

Features

• Sunset Policies (RFC 8594)
• Web Linking (RFC 8288)
• API version-aware HTTP clients
  • ex: services.AddHttpClient("test").AddApiVersion(1.0)
  • If the server reports API versions, the use of deprecated API versions and their sunset polices are passed to ILogger

ASP.NET Core

• Support .NET 6.0 (LTS)
• Support Minimal APIs
• Support OData 8.0 (finally! 🎉)

Enhancements

All Platforms

• Performance (ex: more Span<T>, no Regex, fewer allocations, etc)
• ApiVersion and related attributes now allows double (ex: new ApiVersion(1.0), [ApiVersion(1.0)])
• ApiVersion.Status now allows . (ex: 2.0-beta.1, 2022-04-01-preview.1)
• ApiVersion.Parse is supplanted by IApiVersionParser via ApiVersionParser.Default
  • This now makes end-to-end customization of ApiVersion possible (ex: you can add, parse, and format a patch or revision version component if you really want it)
• All errors now use Problem Details (RFC 7807)
• 404, 405, and 415 are now properly returned in accordance with configured versioning methods without requiring additional configuration or customization
• Namespace-to-API Version parsing has been lifted out into NamespaceParser
  • You can extend/customize the behavior or simply use NamespaceParser.Default for the same old out-of-the-box implementation

.NET 6.0

• ApiVersion supports ISpanFormattable

ASP.NET Web API

• .NET Framework 4.5 is still supported, but .NET Framework 4.7.2 is added as a target for performance benefits when supported
• UrlHelper.WithoutApiVersion() extension (useful when generating links from versioned to version-neutral routes)

ASP.NET Core

• IUrlHelper.WithoutApiVersion() extension (useful when generating links from versioned to version-neutral endpoints)

Fixes

All of the open issues that could be fixed, have been fixed in this release. These will listed in the forthcoming 5.1 release, but it includes 65+ issues. I will accept reported issues and backport them to 5.1 if they are applicable.

Breaking Changes

This release is essentially a reset and rewrite so many things will be broken from 5.x. The most obvious issues will be new packages. Here is the mapping of old packages to new packages:

Old Package ID	New Package ID
	Asp.Versioning.Abstractions
Microsoft.AspNet.OData.Versioning	Asp.Versioning.WebApi.OData
Microsoft.AspNet.OData.Versioning.ApiExplorer	Asp.Versioning.WebApi.OData.ApiExplorer
Microsoft.AspNet.WebApi.Versioning	Asp.Versioning.WebApi
Microsoft.AspNet.WebApi.Versioning.ApiExplorer	Asp.Versioning.WebApi.ApiExplorer
	Asp.Versioning.Http
	Asp.Versioning.Http.Client
Microsoft.AspNetCore.Mvc.Versioning	Asp.Versioning.Mvc
Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer	Asp.Versioning.Mvc.ApiExplorer
Microsoft.AspNetCore.OData.Versioning	Asp.Versioning.OData
Microsoft.AspNetCore.OData.Versioning.ApiExplorer	Asp.Versioning.OData.ApiExplorer

The second obvious big change will be different namespaces. All previous Microsoft.* namespaces are now Asp.Versioning.*. If you are a library author that targets multiple platforms, this should make things easier going forward; it certainly made it easier in the project itself. Extension methods continue to use the same namespace as the type they correspond to.

Significant individual changes:

• IApiVersionReader.Read now returns IReadOnlyList<string> instead of string?
  • Solves the problem of multiple values for a single key (ex: query string or header)
  • Simplifies reader composition (which naturally may have multiple values)
  • Makes reading duplicate values non-exceptional, which is also valuable in error reporting
• IReportApiVersions.Report now accepts the entire response instead of just headers
• IErrorResponseProvider no longer exists; it is supplanted by IProblemDetailsFactory and Problem Details (RFC 7807)
• The following old extension methods were moved to the new ApiVersionMetadata type:
  • GetApiVersionModel(ApiVersionMapping) → GetApiVersionMetadata()
  • GetApiVersionModel() → ApiVersionMetadata.Map(ApiVersionMapping.Explicit)
  • MappingTo(ApiVersion) → ApiVersionMetadata.MappingTo(ApiVersion)
  • IsMappedTo(ApiVersion) → ApiVersionMetadata.IsMappedTo(ApiVersion)

Routing behavior has changed to more accurately return 404, 405, or 415 when appropriate. 400 is still returned in known, invalid requests such as an unspecified API version when required.

For ASP.NET Core, the setup is now a fluent interface of chained configuration options:

services.AddApiVersioning()     // Core API Versioning services with support for Minimal APIs
        .AddMvc()               // API versioning extensions for MVC Core
        .AddApiExplorer()       // API version-aware API Explorer extensions
        .AddOData()             // API versioning extensions for OData
        .AddODataApiExplorer(); // API version-aware API Explorer extensions for OData

Future Release

The following are features and enhancements still under consideration before the final release:

• Support OData query options for non-OData controllers
• Alignment to Improve Minimal API Routing with Grouping, which will matter for .NET 7.0

Feedback

I want to hear your feedback. What do you like? What do you not like? I want to give the community a chance to play with the latest bits and provide any final thoughts before committing to the final release. Now would be the time for any other name changes or other significant refactoring that could cause additional disruption going forward.

Administrative

TL;DR

• This project is now officially part of the .NET Foundation (🎉)
• Code signing still isn't setup, which will hold up the official release, including the 5.x patches