Nicolas De loof

@NReilingh because you change volume `name` (which is equivalent to defining another volume). If you change another configuration attribute in a volume, this won't get detected.

> The only change was the name attribute, so the original volume should not have been recreated (causing data loss) `name` is not just a configuration attribute, but actually the...

also see https://github.com/docker/compose/issues/9203 for a comparable issue, which comes without the risk we delete user data while re-creating a volume after configuration changed!

The [actual implementation](https://github.com/docker/go-units/blob/master/size.go#L86) used by compose-go relies on binaryMap (KiB, MiB ...). Feel free to open a PR on the spec for clarification

This is something I considered in the past but not a trivial one: as we show progress UI for the stop sequence, we can't mix with logs. Would need to...

I wonder this is caused by parallelism used by compose to orchestrate service images build (required to support cross-services base image references). We get a comparable issue reported running compose...

> I would expect services not activated by profiles to be considered orphans Those are not. They are well defined in the compose model, but disabled. Some compose users rely...

@blop nice catch. profile should not be included in service hash so no such recreate takes place, could you please create a dedicated issue ?

@hh10k yes it is. Running command with `&&` you truncate model from inactive profiles, so the result isn't the same. `docker compose config` role is **not** to keep the model...

why don't you use `docker compose up test` if you'd like compose to manage this execution with full lifecycle support ?