Skip to content

[Feature Request] Publish :latest from the release branch instead of the dev branch #797

Description

@ryan-winkler

Describe the solution you'd like

Swap which branch feeds which container tag:

Tag Today Proposed
:latest latest branch (dev integration) release branch (stable)
:release release branch keep as-is, or alias
:dev (new) latest branch (dev integration)

The problem

latest is Docker's implicit default tag. A bare docker pull ghcr.io/dannyvfilms/floppy with no tag resolves to :latest, and Docker convention reads that as "newest stable release." In Floppy it currently means "head of the dev integration branch."

That mapping fights the registry's own semantics, and every documented install path leads users straight into it:

Source Tag handed to the user
README.md:33 quickstart floppy:latest
docker-compose.yml:6 floppy:latest
docker-compose.postgres.yml:6 floppy (bare → resolves to :latest)

So every self-hoster who follows the quickstart is subscribed to the dev channel by default, and :release is the thing you have to already know to ask for. A dev channel should be opt-in; here the opt-in is the default.

Merges to latest are frequent — ten publishes on 2026-08-15 alone — so breaking changes reach that default tag immediately, with no gate between merge and every default deployment.

Describe alternatives you've considered

  • Status quo + documentation. Point the README and compose files at :release and leave the tags alone. Cheapest, no registry churn, but a bare docker pull still silently lands on dev, and it leaves :latest meaning the opposite of what the wider ecosystem assumes.
  • Rename latestdev only (no :latest remap). Adds the opt-in channel but leaves :latest unpublished or stale, which breaks existing pulls harder than remapping does.
  • Do nothing. Defensible if the project intends self-hosters to track dev. If so, that intent should at least be stated at the top of the README quickstart rather than implied by a tag name.

Additional context

This is not the same thing as #782. That issue was about PR builds publishing pr-N tags on every commit and is fixed by #793. The channel question came up while confirming that merges to latest still publish — they do, unchanged.

Worth noting for the record: the original reporter of #782 suggested a :dev tag. Applied to PR builds that would have been worse than the status quo — a shared mutable tag that any open PR could overwrite, last-writer-wins. Applied to merges, which is what this issue proposes, the instinct is right.

This is a breaking change for existing users and needs a rollout, not a flip:

  1. Start publishing :dev from the latest branch while :latest keeps its current meaning
  2. Update README and both compose files to name a tag explicitly
  3. Announce the date :latest starts tracking release
  4. Flip, and keep publishing :dev indefinitely

Deliberately not bundled into #793, which is scoped to stopping PR publishes.

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions