Add image mount subpath option to compose schema

[LaurentGoderre]

- What I did

Add image mount subpath option to compose schema

- Human readable description for the release notes

Add image mount subpath option to compose schema

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[thaJeztah]

As the 3.13 schema was already released, we probably need a 3.14 schema; the way we approached that in previous ones was to have a PR with 2 separate commits; the first commit would copy the schema as-is to the new version, then a second commit to apply the changes; this allows for reviewing the changes that are added in isolation; for example, see this one that did the last update;

• Handle networks.driver_opts for a service #5125

[thaJeztah]

I should say "no changes" for that first commit; except for updating the version in the schema 😅 (but the linked PR should probably give that information)

[LaurentGoderre]

Done!

[thaJeztah]

Ah! So, the first commit probably should update at least the defaultVersion as well, and we may want to update some of the versions used elsewhere (see a731722)

For docker stack, the default is nowadays to pick "latest" (defaultVersion), but it allows specifying a specific version to downgrade features (for compatibility with different versions of the CLI).

Just to be sure; was this change in the schema also added in the compose-spec (which is what docker compose uses)? https://github.com/compose-spec/compose-spec

[LaurentGoderre]

It was not. I wasn't sure how the two were related

[thaJeztah]

It's .. complicated..

The "v3" compose schema in this repository pre-dates the compose-spec, which was based on merging the "v2" and "v3" specs, but also removed versioning and re-introduced features that were deprecated in v3.

Ultimately, we should look at migrating this code to use the compose-spec, but there are some subtle differences that need future discussion before we do so.

In the meantime, for features that are to be supported by the v3 schema in this repository, we basically take the approach to;

• propose changes in the compose-spec
• then implement them in https://github.com/compose-spec/compose-go (for docker-compose)
• and implement them here (docekr/cli)

The above is to avoid the v3 schema to be introducing a feature that's not accepted by the compose-spec, it's ok(ish) to have features in the compose-spec that are not (yet) supported by the v3 schema, but we want to avoid the reverse (v3 adding features that are not supported in the compose-spec).

If needed, I'm sure @ndeloof or @glours would be able to help with the steps for the compose-spec

[ndeloof]

Actually I had in mind to stop adding more options to volumes and introduce a mount section, to better align with the docker CLI UX, as those are not strictly equivalent.