Nicolas De loof

@konstruktoid thanks for reporting. I guess doc was updated for v2.5 release but this is actually link for docker-compose 1.x completion

This distinct behavior between short and long syntax is a weird legacy decision. It has been excluded from the [Compose Specification](https://github.com/compose-spec/compose-spec/blob/master/spec.md#volumes) as "_implementation specific_". The actual reason for this is...

right, as we skip normalization, we don't declare the implicit `default` network anymore. question: why do you explicitly assign your services to `networks: default`, as .. you don't need to!

right, good point

Thanks for looking into this. I'd prefer we don't need to make changes to the copied `parseSecurityOpts` function, so that we can make this one public in docker/cli and use...

related: https://github.com/docker/cli/pull/3616

We for sure can fix this but https://github.com/docker/compose-cli/issues/984 would be a better way so that we don't depend on original compose file and variables

V2 indeed doesn't reproduce this V1 warning, this is something we should consider. > documentation is not very clear about this apparently working port-range feature in V1 Indeed, I didn't...

ran a quick test, and this actually isn't an issue with replicas. Even using `replicas: 1` container is bound to the whole range, not "_somrwhere within the specified range`_ ```...

confirmed. compose-v1 creates container as: ```json "PortBindings": { "5000/tcp": [ { "HostIp": "", "HostPort": "6005-6015" } ] }, ``` compose-v2 creates container as: ```json "PortBindings": { "5000/tcp": [ { "HostIp":...