From 32e0aaff33b72ec685d4341411c4cdcbc9c043f9 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 9 Sep 2026 19:12:12 +0000 Subject: [PATCH] Add bump-nextcloud-version skill Documents the two-commit process this repo uses to track a new Nextcloud major version, derived from the actual history: 7b240ab/512c770 for the stable35/NC36 cycle, 923d4d0/7579129 for stable34/NC35, bfa10c1/29d23a5 for stable33/NC34. 1. Create stableNN off master: drop the "-dev" suffix from appinfo/info.xml's and switch from the floating "master" tag to the fixed release version. 2. Bump master's to NN+1-dev and to NN+1, leaving on "master". Unlike workflow_ocr, this repo has no CI dependency on the Nextcloud server source, so there are no server-version/ocp-version CI matrices to repoint - the whole cycle is appinfo/info.xml only. Also notes the build.yml vs. appstore-build-publish.yml split (the fixed image tag is only actually built later, via a GitHub release) and points at the equivalent skill in the workflow_ocr companion repo. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01F9n81aZgDyY6jdBC4yxyW6 --- .../skills/bump-nextcloud-version/SKILL.md | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 .claude/skills/bump-nextcloud-version/SKILL.md diff --git a/.claude/skills/bump-nextcloud-version/SKILL.md b/.claude/skills/bump-nextcloud-version/SKILL.md new file mode 100644 index 0000000..0d49691 --- /dev/null +++ b/.claude/skills/bump-nextcloud-version/SKILL.md @@ -0,0 +1,112 @@ +--- +name: bump-nextcloud-version +description: Create the next stableNN branch and bump master to the next Nextcloud dev version, once nextcloud/server has cut its own stableNN branch. Use only when explicitly asked to prepare workflow_ocr_backend for a new Nextcloud major version. +disable-model-invocation: true +--- + +Only run this when Nextcloud has actually cut a new `stableNN` branch on +`nextcloud/server` for the version this repo's `master` currently targets. Verify with +`git ls-remote https://github.com/nextcloud/server stableNN` before doing anything — if it +doesn't exist yet, there is nothing to do. + +Unlike a typical Nextcloud app, this repo has **no CI dependency on the Nextcloud server +source** (it's a standalone Python ExApp, not a PHP app booted inside Nextcloud), so there +are no `server-versions`/`ocp-version` CI matrices to repoint. The whole cycle is two small, +`appinfo/info.xml`-only commits, done back to back in the same session. Reference commits +for the most recent cycles: `7b240ab` + `512c770` (`stable35` / NC36), `923d4d0` + `7579129` +(`stable34` / NC35), `bfa10c1` + `29d23a5` (`stable33` / NC34). Read one with `git show` +before starting if anything below is unclear — they are the ground truth this skill was +written from. + +## 0. Preconditions + +- `appinfo/info.xml`'s `` (min and max are always + the same single value) and `N.NN.0-dev` — the `-dev` suffix marks + `master` as still developing against `NN`, not yet released. Call the target `NN`; the new + branch is `stableNN`, the new master target is `NN+1`. +- `stableNN` does not already exist in this repo: + `git ls-remote origin stableNN` returns nothing. + +## 1. Create `stableNN` + +```bash +git fetch origin master +git checkout -b stableNN origin/master +``` + +In `appinfo/info.xml` on `stableNN` only, drop the dev suffix and switch the published +Docker image tag from the floating `master` tag to this fixed release version: + +```diff +- 1.NN.0-dev ++ 1.NN.0 + ... +- master ++ 1.NN.0 +``` + +Nothing else changes — no CI file references a Nextcloud server branch here. Commit message +pattern: `chore: Create stableNN`. + +`1.NN.0` is what `workflow_ocr`'s `appinfo/info.xml` +(`` on its own `stableNN`) will point at once that image tag +actually exists — it doesn't exist yet at branch-cut time. `.github/workflows/build.yml` +only builds/pushes on pushes to `master`, so this fixed tag gets built later by +`appstore-build-publish.yml`, which fires on a GitHub *release* and reads the tag straight +out of `` — i.e. from a release cut on `stableNN` once one exists. Don't try to +build or push the image as part of this skill; that happens through the normal release +process, separately. + +## 2. Bump `master` to `NN+1` + +Switch back to `master` (not `stableNN`) for this part. In `appinfo/info.xml`: + +```diff +- 1.NN.0-dev ++ 1.(NN+1).0-dev + ... +- ++ +``` + +`` stays `master` on `master` — leave it alone. + +Commit message pattern: `chore: master is now NC{NN+1}`. + +### Also check, opportunistically — not every cycle + +If the new NC target's supported ecosystem changed in a way this repo tracks (Python +version support, `ocrmypdf` version, `nc-py-api` compatibility), that's an independent +`requirements.txt`/`requirements-dev.txt` dependency bump — see e.g. `448b341` ("Prepare +Nextcloud 33"), which bumped `nc-py-api` and `ocrmypdf` alongside the version, plus the +`AA-VERSION` fallback defaults in `test/test_harp_integration.py` (`"32"` → `"33"`, an +AppAPI-protocol-version placeholder, not the Nextcloud major version). This has not +recurred every cycle (unchanged since NC33→34) — only touch it if you have an actual reason +to, not as part of the version-number bump itself. + +## 3. Verify + +```bash +make deps && make test # on both stableNN and master +make build # confirms the Dockerfile still builds cleanly +``` + +`make harp-integrationtest` needs a working Docker CLI and is worth running if you touched +anything beyond `appinfo/info.xml`. There is no server checkout to verify against — unlike +`workflow_ocr`, nothing here depends on the actual `nextcloud/server` source at `stableNN`. + +## 4. Companion repo + +`workflow_ocr` goes through an equivalent two-step cycle, on its own schedule — often the +same day, but always as its own separate operation with a different shape (it *does* pin CI +matrices to a server branch; see its `bump-nextcloud-version` skill). Check whether it has +already been done: + +```bash +git ls-remote https://github.com/R0Wi/workflow_ocr stableNN +``` + +If not, do it there too (or tell the user it still needs doing — it is a different repo and +this skill does not reach into it). The two repos' `appinfo/info.xml` versions and +`` should end up matching after both cycles are done, modulo the +`-dev` suffix this repo uses between releases and `workflow_ocr` does not.