chore: raise Nextcloud floor to 32 (PHP 8.3) on main

[rubenvdlinde]

Raises the Nextcloud floor on main from 28 to 32 and the PHP floor from 8.1 to 8.3. max-version="33" is preserved unchanged (not normalised).

Note: main's floor really is 28 here — but development is already at 32. Grep-based readings of this file produced a false 28 for the development branch today; all values in this PR were read with an XML parser.

Why

Product directive from the PO (Ruben): the fleet standardises on Nextcloud 32 so it can require PHP 8.3 — "we want php 8.3 so going for min version nc 32 fleet wide is a good thing."

The governing rule (openconnector#1172 / openconnector#1173): an app's min-version must be >= the max of every <app> dependency's floor, or the App Store advertises a range the app cannot deliver — the dependency refuses to install and the app is non-functional there.

Re-measured on this branch's date with an XML parser (not grep): openregister@development appinfo/info.xml declares nextcloud min-version="32" max-version="34" and php min-version="8.3" (openregister#2384).

Shape

Floor-only PR opened directly against main. Reason: main trails development by 188–5206 commits across this fleet, so a development -> main merge would be a full release, not a floor fix.

Measurement note: appinfo/info.xml in these repos contains literal Nextcloud-dependency examples inside XML comments, so all before/after values here were read with xml.etree.ElementTree, never grep. The added comment is deliberately prose only — it contains no XML element syntax, because floor guards count raw regex matches of the nextcloud element across the whole file including comments, and a quoted example would trip as a second contradictory declaration. Validated before push: file parses as XML, and <nextcloud\b[^>]*> matches exactly once.

CI

No CI change in this PR — there is no leg to drop. Verified: main carries the old self-contained code-quality.yml shape (a php-checks matrix of PHP Lint / PHPCS / PHPMD / Psalm / PHPStan / PHPUnit plus frontend-quality). Nothing references the shared ConductionNL/.github/.github/workflows/quality.yml, and no workflow on main installs Nextcloud at all, so no nextcloud-test-refs input exists.

Follow-up (deliberately NOT done here)

main's code-quality.yml pins shivammathur/setup-php to php-version: '8.1' (line 33), while appinfo/info.xml will declare a PHP floor of 8.3 after this merge. CI therefore lints on a PHP version the app no longer claims to support. Flagged as a follow-up; this legacy workflow is intentionally left alone so this stays a floor-only change.

Measured, same follow-up: composer.json on main declares "require": {"php": "^8.1"} and pins "config": {"platform": {"php": "8.1"}}. Psalm's own log on this PR confirms it resolves Target PHP version: 8.1 (inferred from composer.json). So after this merge the PHP floor is declared in appinfo/info.xml only; composer.json and CI still say 8.1. Deliberately left alone to keep this a floor-only change.

Pre-existing CI debt on this PR (not caused by this change)

PHPStan (76 errors) and Psalm (3 errors) fail. Both analyse lib/ PHP only — neither reads XML — so an appinfo/info.xml edit cannot cause them. The errors are unresolved symbols: OCP\IAppConfig, OCP\Settings\ISettings, OCP\AppFramework\Http\TemplateResponse (the nextcloud/ocp stubs are not installed in this legacy workflow) and OCA\OpenRegister\Event\DeepLinkRegistrationEvent. main has no Code Quality run of its own to compare against — this workflow triggers on pull_request only, so it has never run on a main push.

[rubenvdlinde]

Closing for the same reason ConductionNL/openregister#2392 and ConductionNL/docudesk#406 were closed on 2026-08-09: this targets main directly, and changes flow development → beta → main for app repos.

Verified before closing — development already carries it:

<php min-version="8.3"/>
<nextcloud min-version="32" max-version="34"/>

So the change is not lost, it is waiting on a release rather than on this PR. main is 2,012 commits behind development here; its info.xml is stale for the same reason its CI is (Psalm + PHPStan fail against a toolchain that old). Patching the manifest on main in isolation would make one line honest on a branch that is otherwise thousands of commits out of date.

This also retires the standing plan item "fix each repo's main CI green before landing the floor PRs". That plan assumed main could be made green in isolation. It cannot: main is 5,270 commits behind in openregister, 2,012 here, 413 in docudesk, and the failures are stale-toolchain (e.g. openregister's frontend suite fails with ReferenceError: OC is not defined), not discrete bugs. main goes green when a release carries development into it, and that route runs through beta, which is human-gated.