[aiordache]

This update introduces an unified compose format that should be compatible with all v2.x and v3.x compose files.
The version field is made optional (the format is automatically detected from the structure of the file).
** version was required to distinguish with 1.x format
For each version, docker-compose validated against its specific schema. Now we have only 2 schemas:

• v1 schema
• compose_spec schema (merged v2.x and v3.x)

Related to the conversion from v3 to v2 using the --compatibility flag: the deploy field was being ignored unless this flag was passed and only one container per service was created.

We now apply the properties from deploy regardless of the --compatibility flag.

Test sample:

version: '3.8'
services:
  test:
    image: nginx
    deploy:
      replicas: 3

BEFORE:

One container per service was created unless we pass --compatibility.

$ docker-compose up -d
WARNING: Some services (test) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
Creating network "hello_default" with the default driver
Creating hello_test_1 ... done

NOW:
Version field is optional, we can either remove it or leave it as it is, result is the same:

services:
  test:
    image: nginx
    deploy:
      replicas: 3

$ docker-compose up -d
WARNING: Some services (test) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
Creating network "hello_default" with the default driver
Creating hello_test_1 ... done
Creating hello_test_2 ... done
Creating hello_test_3 ... done

Same we get from a v2 file:

services:
  test:
    image: nginx
    scale: 3

v2.x and v3.x schema merging relates to #7201
The removal of compatibility mode relates to https://github.com/docker/dev-tooling-team/issues/121

[jamshid]

This is great I was just asking for --compatibility to be the default in #7594, so glad to hear the frustrating version incompatibility is being removed.
Have memswap_limit and mem_swappiness equivalents been added to deploy resources?

[aiordache]

Have memswap_limit and mem_swappiness equivalents been added to deploy resources?

@jamshid we don't have yet equivalent properties in deploy for these. With the unified schema we bring them back as service properties.

I opened an issue on the compose-spec to see if we can have them added/moved to deploy: compose-spec/compose-spec#90

[melicerte]

I don't clearly understand the consequences of this update.

I have single service extension with extends working with version: "3.5".
This means I can mix up features from 2.x and 3.x like shm_size with no problem ?

[EricHripko]

Yes @melicerte - you're understanding this correctly 👍 Post-1.27.x, version attribute becomes optional and you can mix 2.x/3.x attributes in the same Compose file 🙂

[melicerte]

Thanks @EricHripko this is amazing !

[melicerte]

However shouldn't documentation be updated accordingly ?
For example, concerning extends here https://docs.docker.com/compose/extends/ it could be specified that it works from docker-compose 1.27 and up.

[EricHripko]

Yep, sounds like a PR to docker.github.io is needed 🙂