info.xml violates the XSD element order — lint fails on development and every PR

[rubenvdlinde]

quality / info.xml lint fails on development and therefore on every PR. The manifest violates the element order info.xsd requires.

Validated locally against the real schema (fetched from https://apps.nextcloud.com/schema/apps/info.xsd):

appinfo/info.xml:28: Element 'category': This element is not expected. Expected is one of ( licence, author ).

and, once that one is moved, two more appear behind it:

appinfo/info.xml:53:  Element 'php': This element is not expected. Expected is one of ( architecture, backend ).
appinfo/info.xml:112: Element 'repair-steps': This element is not expected. Expected is one of ( settings, activity, … ).

The canonical orders, extracted from the XSD

Top level:

id name summary description version licence author namespace types documentation
category website discussion bugs repository screenshot donation dependencies
background-jobs repair-steps two-factor-providers commands settings activity
dashboard fulltextsearch navigations contactsmenu collaboration openmetrics
sabre trash versions external-app

Inside <dependencies>:

php database command lib owncloud nextcloud architecture backend

What is out of order here

element	is	should be
category	between licence and author	after namespace
nextcloud	before php	after lib/owncloud
repair-steps	after commands	before commands
settings	after navigations	before navigations

⚠️ One thing to resolve first

<app> does not appear anywhere in that XSD — grep -c 'name="app"' returns 0 — yet <dependencies><app>openregister</app></dependencies> is load-bearing here, and the surrounding comment builds the whole min-version="32" argument on it (#1172).

So either the fetched schema is not the one the lint job uses, or <app> has never been schema-valid and the job is newly surfacing that. That question decides whether this is a reordering or something larger, and it should be answered before anyone moves elements around.

I attempted the reordering and backed it out for exactly that reason: rewriting a live manifest against a schema that contradicts the file's own documented dependency contract is not a change to make on the way past.

[rubenvdlinde]

Resolved: <app> is invalid AND unenforced

I flagged this as the question blocking the reorder. It has a definite answer, and it is worse than "which schema".

1. CI validates against the appstore schema, not apps.nextcloud.com:

curl -sSfL -o info.xsd \
  https://raw.githubusercontent.com/nextcloud/appstore/master/nextcloudappstore/api/v1/release/info.xsd
xmllint --noout --schema info.xsd appinfo/info.xml

Fetched that exact file (34,374 bytes). grep -c 'name="app"' → 0. Its dependencies children are:

php database command lib owncloud nextcloud architecture backend

So <dependencies><app>openregister</app></dependencies> is not valid in the schema CI actually uses — and my earlier uncertainty about which schema does not save it, because both agree.

2. Nextcloud does not enforce it either. lib/private/App/DependencyAnalyzer.php analyses:

analyzeArchitecture analyzeCommands analyzeDatabases analyzeLibraries
analyzeOS analyzePhpVersion analyzeServer analyzeServerVersion

There is no app analysis. Confirmed on the running NC 34 container.

3. No shipped app uses it. Zero of the 56 apps with a <dependencies> block declare <app>; e.g. Circles declares only <nextcloud min-version="34" max-version="34"/>.

What this means for the min-version="32" comment

The comment builds its whole argument on that element:

min-version is 32, NOT 28, because <app>openregister</app> above is a HARD dependency and openregister declares min-version="32".

The conclusion is still right — openconnector genuinely cannot work without openregister, and openregister needs NC 32, so advertising 28 offers a range this app cannot deliver (#1172). But the mechanism it cites does not exist: the server never reads that element, so nothing enforces the dependency at install time. It documents an intent, not a constraint.

So the reorder is unblocked, with one decision attached

category, nextcloud/php, repair-steps/commands and settings/navigations can all be moved to the XSD order — that part is mechanical.

⚠️ What to do with <app>openregister</app> is a product call, not a lint fix:

• remove it — it validates, and loses nothing the server was doing; the reasoning survives as the comment
• keep it — accept the lint failure, or exclude that element, if Conduction tooling (hydra gates, manifest checks) reads it

I am not choosing between those on the way past, because "delete a declared dependency" and "keep CI red" are both consequential and neither is a formatting decision. Everything else in this issue is ready to apply once that is settled.