nextcloud / nextcloud/docker

Clarify versioning/update policy in the README

Open
#2,262 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

1. To develop docs enhancement meta overview
Dominant language
Shell
Stars
7.4k
Forks
1.9k
PR merge metrics
No merged PRs in 30d

Description

Breadcrumbs for down the road... (Mostly for myself).

  • Context
    • Docker Official images and what that means
    • Base image updates (eco-system rebuilds)
  • Nextcloud Server releases (upstream bumps)
  • Image releases
    • bugs fixes
    • enhancements
    • upgrades of underlying bits (e.g. a new major PHP or underlying distribution version)

Production Docker tags:

  • Upstream supported stables (proposed)
    • latest
    • previous
    • last
  • Generic
    • stable / production

Tracking this in: #2265


Immutable:

  • No such thing technically since what a tag points to can always be changed
  • We attempt to make specific tags semi-immutable at the Dockerfile level, but the images themselves referenced by these tags will technically always change automatically whenever the underlying base images (debian, alpine, php) are updated (generally for security). This is a byproduct of how Docker base images and Docker Official images work.
  • The only truly immutable option - if you require that - is to reference your images by their digest. The caveat being you're 100% responsible for security updates.

General recommendations:

  • Pin your image references to something. Rule of thumb: a major release or one of { latest, previous, last }

  • Tagging policy
    • latest/previous/last match upstream
    • stable/production generally matches ?

  • Breaking changes
    • ?

  • Image versions
  • Nextcloud Server versions
  • Base image versioning/rebuilding
  • Image tags

  • Mutable tags
  • Rolling tags
  • Semo-immutable
    • e.g. "29.0.5"
  • Digests (immutable/BOM use)

Changelog:

  • Release notes (high-level / quick summary)
  • Commit log (detailed /

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README and the linked tracking issue #2265; review the listed questions about tags, releases, base-image rebuilds, immutability, breaking changes, and changelog content. Done means the README clearly explains the versioning and update policy, including production tags, mutable versus semi-immutable references, digests, and general recommendations.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
devops, documentation, release
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.