Docker for Mac updates Compose and restores predictable service container names

A generated container name can become an interface when scripts and operators use it to locate a running service. Compose 1.23.0 changed that interface by appending a random suffix to names. Compose 1.23.2 reverses the change for containers created by docker-compose up, and Docker for Mac includes that update in its December 7 2.0.0.0-mac81 build. The desktop release entry records the bundled update.

This is a maintenance build within the desktop's new numbering scheme. The same release history already lists 2.0.0.0-mac78 on November 19, with the new scheme and the engine update. December's entry identifies Compose 1.23.2 as the upgrade. Treating it as the initial arrival of stable Desktop 2.0 would obscure what this particular build changes.

I value Docker's repeatable description of an application environment. Generated identifiers need a similarly clear purpose because they often escape into the tools used around that environment. A name intended to prevent one-off task collisions has a different job from the conventional name of a long-running service container.

Collision avoidance changed the default naming contract

The Compose changelog at version 1.23.2 describes the preceding change and its reversal. Version 1.23.0, released October 30, changed the naming pattern from project, service and index to the same components followed by a randomly generated hexadecimal suffix. Its release note explicitly asked users to update scripts relying on the old scheme.

That release also fixed collisions between parallel run commands for the same service. The motivation is understandable. Several one-off invocations need distinct names if they execute concurrently. A name derived only from the service's usual identity does not by itself distinguish independent temporary executions.

The November 28 maintenance release draws a narrower boundary. It restores the previous naming behavior for up because the random suffix caused addressability issues. Containers created by run retain randomly generated names to avoid parallel collisions. The correction preserves the purpose of uniqueness where the changelog says it is needed, while removing the broad naming change from ordinary service startup.

This is more informative than describing the release as a general return to deterministic names. One-off containers still have different behavior. A script using Compose needs to identify which lifecycle it is dealing with before assuming that the same naming rule applies. The command that creates the container is part of that interpretation.

The tradeoff concerns compatibility with existing callers. Random identifiers can prevent accidental reuse of a name, but they also remove predictability that other tooling may depend on. The changelog's reversion acknowledges that service container addressability was affected. It does not establish that every dependency on a generated name is ideal, only that the naming change had consequences beyond Compose's internal implementation.

A desktop update delivers a separately released client

Compose 1.23.2 existed before the December desktop build. Its own release date is November 28, while mac81 delivers it on December 7. These dates describe different events. A user managing Compose independently could encounter the correction earlier than someone receiving it through the desktop package.

The desktop release therefore needs an account of its bundled components as well as its own version. A workstation reporting Desktop 2.0 may still differ from another Desktop 2.0 installation in the Compose maintenance version it contains. The mac suffix identifies the package update, and the Compose version identifies the command behavior relevant to this naming correction.

I prefer that level of precision when discussing a packaging tool. It is possible to retain the same application images while changing the client that creates and names their containers. An image tag alone cannot explain a naming difference introduced by a Compose update.

The patch also corrects configuration interpretation

The Compose maintenance release fixes overrides for storage_opt and isolation in service definitions. An override file expresses an intended difference, so failing to apply those keys means the combined configuration can differ from the author's declaration. The changelog identifies those particular keys without claiming a redesign of all merge behavior.

It also corrects accepted --host values that caused run and exec to fail. This is relevant to the naming distinction because the same commands participate in interactive and one-off work. A command may have a valid target connection and still fail if a particular execution path interprets that target incorrectly.

Windows build corrections address Dockerfile paths and build context URLs, while invalid Compose files now avoid an uncaught validation exception in an affected case. These are separate compatibility fixes within the client update. The desktop package delivers them together with the naming reversion, even though the engine and application images need not change for their effects to become visible.

For ordinary service startup, the immediate result is specific. Containers created by up regain the preceding naming convention. Parallel one-off run invocations continue using random names, preserving the collision-avoidance behavior associated with that lifecycle.