Skip to content

Rename docker-compose.yml to compose.yaml#3213

Open
ivenos wants to merge 1 commit into
fosrl:mainfrom
ivenos:rename-to-compose-yaml
Open

Rename docker-compose.yml to compose.yaml#3213
ivenos wants to merge 1 commit into
fosrl:mainfrom
ivenos:rename-to-compose-yaml

Conversation

@ivenos

@ivenos ivenos commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Description

Aligns the project with the current Compose Specification:

  • compose.yaml is the canonical filename; docker-compose.yml is only a legacy fallback.

Changes

  • Rename the repository's Compose files:
    • docker-compose.ymlcompose.yaml
    • docker-compose.example.ymlcompose.example.yaml
    • docker-compose.pgr.ymlcompose.pgr.yaml
    • docker-compose.mailpit.ymlcompose.mailpit.yaml
    • docker-compose.drizzle.ymlcompose.drizzle.yaml

No behavior change: docker compose discovers either filename, so existing setups are unaffected. There was no top-level version field to drop, and none of these files are referenced by exact name anywhere in the repo. These are pure renames (100% similarity).

The installer (install/) is intentionally left unchanged: it generates and manages the end user's deployment docker-compose.yml and is coupled to that exact filename (backups, -f docker-compose.yml, podman-compose). Renaming it there would break upgrades of existing deployments. The resourceExposePortsEditFile UI strings, which point users at that installer-generated file, are likewise left as docker-compose.yml.

How to test?

  • docker compose config in the repo root resolves compose.yaml through auto-discovery (no -f needed).
  • docker compose -f compose.example.yaml config, -f compose.pgr.yaml config, and -f compose.mailpit.yaml config validate successfully.
  • docker compose -f compose.pgr.yaml -f compose.drizzle.yaml config validates (the drizzle overlay depends on the db service from the pgr file, same as before the rename).

@AstralDestiny

Copy link
Copy Markdown
Contributor

Eh that's a bit messy to use -f If I want to overlay I just use profiles or overrides. Profiles preferably, Just depends if the CI/CD tools in the repo are looking for docker-compose or just running the raw commands, Would likely look into that.

@AstralDestiny

Copy link
Copy Markdown
Contributor

Else looks fine to me

@ivenos

ivenos commented Jun 5, 2026

Copy link
Copy Markdown
Contributor Author

CI builds via make dev-build-* (just docker buildx build), no compose reference anywhere in .github/ or the Makefile, so the rename's safe there. Only docker-compose.yml left is in install/ and the resourceExposePortsEditFile strings, which point at the installer-generated file.

Profiles would be cleaner than -f, agreed. That overlay predates this PR though, so I kept this one a plain rename. Could be a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants