There is a property at https://docs.spring.io/spring-boot/4.0-SNAPSHOT/appendix/application-properties/index.html#application-properties.web.spring.mvc.apiversion.default to specify a default version and a strategy for API versioning like:

spring:
  mvc:
    apiversion:
      default: 1.0.0
      use:
        header: X-Version

It would be nice if deprecation could be specified in a similiar way, e.g.:

spring:
  mvc:
    apideprecation:
      version: 0.0.1
      date: 2025-09-01
      # default = ZoneId.systemDefault()
      # zone: EST

Comment From: wilkinsona

Thanks for the suggestion. Unfortunately, I don't understand it. The spring.mvc.apiversion properties are for tuning the configuration of Spring MVC's API version support. I don't not see a connection with API deprecation. Can you please explain in more detail?

Comment From: juergenzimmermann

@wilkinsona Spring Framework 7.0.0-M8 provides API versioning as a new feature: https://docs.spring.io/spring-framework/reference/7.0/web/webmvc-versioning.html. There are different options to specify how a client has to submit a version, e.g. inside the request header of GET/POST/... request. On the server side endpoints can be declared with an accompanying version like @GetMapping(..., version = "1.0.0"). As I mentioned in my suggestion Spring Boot already provides an application property so that a version is expected to be submitted within the request header. Additionally Spring Framework 7.0.0-M8 provides a mechanism to declare a version as deprecated. To deprecate a version, e.g. 0.0.1 a configuration class has to be implemented like:

@Configuration
public class WebConfig implements WebMvcConfigurer {
    WebConfig() {}

    @Override
    public void configureApiVersioning(final ApiVersionConfigurer configurer) {
        final var zoneId = ZoneId.systemDefault(); // or e.g. "EST"
        final var deprecationDate = LocalDate.of(2025, 9, 1)
            .atStartOfDay(zoneId);

        final var deprecationHandler = new StandardApiVersionDeprecationHandler();
        deprecationHandler.configureVersion("0.0.1")
            .setDeprecationDate(deprecationDate);

        configurer.setDeprecationHandler(deprecationHandler);
    }
}

Instead of implementing such a class it would be easier to specify the main data by the means of application properties. I hope you can understand my idea (I'm not a native speaker).

Comment From: wilkinsona

Thank you. I understand now. I was just thrown by the proposed properties and realise now that you want to configure the deprecation part of the API versioning feature.

I think this may be possible through properties as long as you don't want to use a custom request predicate. We'd have to support a List or Map so that multiple versions can be deprecated. In YAML, a Map would look something like this:

spring:
  mvc:
    apiversion:
      deprecation:
        '0.0.1':
          deprecation:
            date:
            link:
              uri:
              media-type:
          sunset:
            date:
            link:
              uri:
              media-type:

We could use java.time.ZonedDateTime.parse(CharSequence) to turn the single date property into a ZonedDateTime.

Things may get a little tricky with a custom ApiVersionParser so this'll require a bit more thought. I'm also not completely sure that the properties would be better than code.

Comment From: juergenzimmermann

@wilkinsona, thank you. This is what I was thinking about.

Comment From: wilkinsona

We've discussed this today and decided that we don't think it's a good fit for configuring with properties. It doesn't feel like something that would benefit from being externalizable and there are also a number of settings that can't be configured at all using properties such as the predicate support. Thanks anyway for the suggestion.