Service API versioning using OData is similar to the normal configuration with a few slight variations. Each implemented OData controller has an associated entity set and each entity set is defined in an Entity Data Model (EDM). Once we introduce API versioning, each versioned OData controller now needs an EDM per API version. To satisfy this requirement, we'll use the new VersionedODataModelBuilder, build a collection of EDMs for each API version, and then map a set of routes for them.

public class Startup
{
    public void Configuration( IAppBuilder appBuilder )
    {
        var configuration = new HttpConfiguration();
        var httpServer = new HttpServer( configuration );

        configuration.AddApiVersioning();

        var modelBuilder = new VersionedODataModelBuilder( configuration )
        {
            ModelConfigurations =
            {
                new PersonModelConfiguration()
            }
        };

        configuration.MapVersionedODataRoute( "odata", "api", modelBuilder );
        appBuilder.UseWebApi( httpServer );
    }
}

var builder = WebApplication.CreateBuilder( args );

builder.Services.AddControllers().AddOData();
builder.Services.AddProblemDetails();
builder.Services.AddApiVersioning()
                .AddOData( options => options.AddRouteComponents( "api" ) );

var app = builder.Build();

app.MapControllers();
app.Run();

It is possible to imperatively use:

.AddOData( options => options.ModelConfigurations.Add( new PersonModelConfiguration() ) )

however, it is typically unnecessary because this will automatically happen via dependency injection.

Important: Calling AddControllers().AddOData( options => options.AddRouteComponents( ... ) ) will be completely ignored by API Versioning. Due to the OData design, it is impossible to extend or customize this behavior. Instead, you need to use AddApiVersioning().AddOData( options => options.AddRouteComponents( ... ) ). The standard AddOData configuration can still be used to configure global query option settings.