What
On the 0.1.x line, composer.json requires:
"restruct/dot-static": "@stable"
@stable is unbounded, so a fresh composer install with no lock file resolves to whatever the newest dot-static release happens to be — currently the 2.x line.
Why it matters
The 0.1.x line is what SilverStripe 3.x-era consumers pin to. Those projects cannot use dot-static 2.x, so an install without a committed lock can silently produce a tree that will not run, with no constraint error to explain it.
Observed in two consumer checkouts:
- an SS 3.5 project:
docsys-tools 0.1.1 + dot-static 1.3 (what @stable resolved to at the time, preserved only by the project's composer.lock)
- an SS 4 project:
docsys-tools 0.1.2, same unbounded constraint
Both are currently reproducible only because the consumer projects committed lock files. Nothing in the package itself constrains the resolution.
Already correct on the current line
The 1.0.x line pins properly (restruct/dot-static: ^2.0, restruct/xpdf-static: ^1.0), so this is limited to the legacy branch.
Suggested
If 0.1.x is still considered supported for SS3/SS4 consumers, pin it to the dot-static major those projects can actually run (^1.0, based on the 1.3 resolution observed above — worth confirming against a real SS3 install before tagging). If 0.1.x is end-of-life, saying so in the README is enough, and this can be closed as won't-fix.
Low severity: no known broken install today, since consumers are lock-protected. Filed per the standing module-findings routing rule so it does not live only in a project session.
What
On the
0.1.xline,composer.jsonrequires:@stableis unbounded, so a freshcomposer installwith no lock file resolves to whatever the newest dot-static release happens to be — currently the 2.x line.Why it matters
The
0.1.xline is what SilverStripe 3.x-era consumers pin to. Those projects cannot use dot-static 2.x, so an install without a committed lock can silently produce a tree that will not run, with no constraint error to explain it.Observed in two consumer checkouts:
docsys-tools 0.1.1+dot-static 1.3(what@stableresolved to at the time, preserved only by the project'scomposer.lock)docsys-tools 0.1.2, same unbounded constraintBoth are currently reproducible only because the consumer projects committed lock files. Nothing in the package itself constrains the resolution.
Already correct on the current line
The
1.0.xline pins properly (restruct/dot-static: ^2.0,restruct/xpdf-static: ^1.0), so this is limited to the legacy branch.Suggested
If
0.1.xis still considered supported for SS3/SS4 consumers, pin it to the dot-static major those projects can actually run (^1.0, based on the 1.3 resolution observed above — worth confirming against a real SS3 install before tagging). If0.1.xis end-of-life, saying so in the README is enough, and this can be closed as won't-fix.Low severity: no known broken install today, since consumers are lock-protected. Filed per the standing module-findings routing rule so it does not live only in a project session.