ineiti/nextcloud
0
0
Fork 0
forked from coop-cloud/nextcloud
Code Pull Requests Activity
Files
maintenance.md
nextcloud/MAINTENANCE.md
Linus Gasser 3d7dfed415 Proposing a MAINTENANCE file 
Cobbled together a file with the help of Claude.
I did re-read all of it, manually edited some parts,
and asked for modifications.
2026-05-22 12:23:53 +02:00

3.9 KiB
Raw Permalink Blame History

Nextcloud Recipe Maintenance

Status: DRAFT — open for discussion with co-maintainers and the wider federation. Sections marked (TBD) need collective input before this document is considered ratified.

This document describes how the Nextcloud recipe is maintained. It builds on the floor set by Federation Resolution 025 and follows the MAINTENANCE.md template described in the Co-op Cloud maintainers' docs.

All contributions should be made via a pull request so that quality and consistency stay something others can rely on.

Maintainers

(TBD — to be filled in once the initial group is confirmed; 3 maintainers is the proposed starting size.)

The list above should also be reflected in README.md under the Maintainer metadata field.

Maintainer Responsibilities

This recipe commits to the following, which is tighter than the floor set by Resolution 025 (stable-recipe category):

  • Respond to PRs / issues within 3 working days
  • Apply security patches within 1 week of disclosure
  • Ship patch / minor image updates within 2 weeks of upstream release
  • Adopt major Nextcloud version updates within 1 release cycle of upstream EOL of the previous major (see below)
  • Keep documentation current

In order to meet these responsibilities each maintainer:

  • Watches the repository so notifications arrive
  • Keeps an eye on Renovate updates and helps shepherd them through
  • Has a working contact (Matrix handle or email) reachable by the others

Release cadence

The intent is to track Nextcloud's own release schedule rather than invent our own. In practice this means:

  • Patch releases (e.g. 32.0.x): published to this recipe shortly after upstream, ideally within 1 week. chore(deps) opens the PRs; a maintainer reviews, deploys against a test instance, and tags.

  • Minor releases: same flow as patch releases.

  • Major releases (e.g. 32 → 33): not adopted on day one. We wait for the first one or two upstream patch releases of the new major to land (typically 1–2 months) before promoting it here, to avoid passing the early-adopter cost to operators. Major bumps get their own PR with release notes and an upgrade-path check.

    If people have the time it would be nice to create specially tagged versions which reflect that this is 'bleeding edge'.

  • Co-installed components (Talk HPB, OnlyOffice, Whiteboard, etc.) are bumped alongside or shortly after the matching Nextcloud release.

Pull Requests

A pull request can be merged once it is approved by at least one maintainer. PRs opened by a maintainer need approval from another maintainer. With three maintainers this is workable; if the group shrinks, the rule should be revisited.

Approvals should ideally include a smoke test on a real instance for anything beyond a patch bump — Nextcloud upgrades have a long history of surprising us (see the upgrade notes in README.md), and silent CI is not enough.

Becoming a maintainer

Everyone is welcome to apply:

  1. Watch the repository so you get notifications.
  2. Open a pull request adding yourself to the Maintainer line in README.md and to the list above.
  3. Once an existing maintainer merges the PR, you'll be added to the nextcloud maintainers team (team to be created if it does not yet exist — TBD).

Stepping down is symmetrical: open a PR removing yourself, and flag it in the federation channels so the group can plan replacement before falling below the Res. 025 floor of one named maintainer.