In case your configuration processing has changed in incompatible ways and you wish to use the "legacy" processing way, you can re-enable it by setting:

spring.config.use-legacy-processing=true

or alternatively, using YAML:

spring:
  config:
    use-legacy-processing: true

which should revert the configuration processing to the 2.3.x equivalent. Do note, however, that this property exists solely to ease the migration of profile configurations from 2.3.x to 2.4.x and will likely be deprecated and removed in a future major release¹, so you should still try to migrate ASAP. To understand the reason for this change and some additional information, read on.

Of note in 2.4.0 are the following two paradigms:

So in Spring Boot 2.4 we’re planning to make two significant changes to the way the properties and YAML files are loaded:

1. Documents will be loaded in the order that they’re defined.

2. Profiles can no longer be activated from profile specific documents.

This change has in fact made the what-overrides-what-when logic considerably simpler to digest, but leads to having to disable some functionality. For example:

my.prop: test

---
spring.profiles: prodprops
my.prop: prod

---
spring.profiles: prod
# no longer works - activating a profile from a profile-specific document!
spring.profiles.include: prodprops
  

would lead to an exception as the configuration attempts to activate a profile from a profile-specific document, which is not allowed anymore.

To cover this use case (and others), profile groups have been added as a feature. This means that to enable your previous behaviour, you would need to create a profile group as follows:

spring.profiles.group.<group>=dev, auth

or alternatively, in YAML:

spring:
  profiles:
    group:
      <group>: dev, auth

Where <group> is the name of your chosen profile group. Note that you can define multiple groups, all of which should have different names. If you then start your application using the <group> profile, all the profiles that are part of that group should be activated.

As a side-note, Spring Boot 2.4.0 additionally added support for multi-document properties files, which look as follows:

test=value
spring.profiles.active=local
#---
spring.config.activate.on-profile=dev
test=overridden value

Note the document separator (#---). This allows you to have similar overriding logic in .properties files as in .yml files.

Again, this and other information is provided in the relevant update post.

¹ If prior deprecations are any indicator, the property should be removed in 2.5.0 at the earliest or 2.6.0 at the latest, with the latter being more likely (and a deprecation as of 2.5.x).

You can use spring.config.import using classpath:

spring.config.import=classpath:application-DEV.yml,classpath:application-auth.yml

Although we have an accepted answer above. But I would share my solution via multiple files. I'm having multiple config files in my project

./
application.yml
application-auth.yml
application-mockauth.yml
application-datasource.yml

The body of application-auth.yml or application-datasource.yml are the same as we're implementing before spring boot 2.4. Minor adjustment will be located inside application.yml

spring:
  profiles:
    group:
      "dev": "datasource,mockauth"
      "prod": "datasource,auth"

Instead of spring.profiles.include, you will group related config with environment name (dev, prod...).