Tracked from `docs/plan.md`'s "Future work: a `since`-version field (not yet implemented)" section.
Motivation
An AROS-derived `LvoEntry` table entry currently has provenance (which AROS source it came from) but no statement of which real AmigaOS version it's actually valid for -- this matters for staying within the current KS/WB 3.1 (V40) target, and will matter again if/when the project later moves to targeting 3.2+ (V47).
Proposed fix (not yet built)
Add a `since: ` field to `LvoEntry`, populated from the NDK Autodocs' own "available since Vxx" statements (a historical fact with even less claim to expression than an offset+register list) -- cross-referenced via a tool in the same spirit as `ndk_verify.py`. Note Autodocs are prose-heavy in a way `.fd` files are not, so that tool needs the same "extract only the version token, never the surrounding text" discipline applied even more carefully than the existing codegen tooling.
Once present, targeting a given OS version becomes a mechanical filter (`since <= V40` for 3.1, `since <= V45` for 3.2) rather than a fresh manual audit each time the target changes.
When to build it
Originally deferred until Phase 3 needed to start making since-version-gated implementation decisions. Worth re-evaluating now given how much of `dos.library`/`exec.library`/`utility.library` has since been implemented -- may be more valuable now as a systematic audit tool than it would have been earlier.
Related note (3.1-compatibility)
AROS's SFDs track AROS's own evolving API, a superset of -- and in places diverging past -- genuine Kickstart/Workbench 3.1 (V40). LVO/register facts pulled from AROS should be treated as candidates to cross-check against 3.1-era documentation (NDK 3.1 Autodocs, RKRM) where a call's signature might have changed since V40, not assumed correct as-is. This `since`-field work would make that cross-check systematic rather than ad hoc.
Tracked from `docs/plan.md`'s "Future work: a `since`-version field (not yet implemented)" section.
Motivation
An AROS-derived `LvoEntry` table entry currently has provenance (which AROS source it came from) but no statement of which real AmigaOS version it's actually valid for -- this matters for staying within the current KS/WB 3.1 (V40) target, and will matter again if/when the project later moves to targeting 3.2+ (V47).
Proposed fix (not yet built)
Add a `since: ` field to `LvoEntry`, populated from the NDK Autodocs' own "available since Vxx" statements (a historical fact with even less claim to expression than an offset+register list) -- cross-referenced via a tool in the same spirit as `ndk_verify.py`. Note Autodocs are prose-heavy in a way `.fd` files are not, so that tool needs the same "extract only the version token, never the surrounding text" discipline applied even more carefully than the existing codegen tooling.
Once present, targeting a given OS version becomes a mechanical filter (`since <= V40` for 3.1, `since <= V45` for 3.2) rather than a fresh manual audit each time the target changes.
When to build it
Originally deferred until Phase 3 needed to start making since-version-gated implementation decisions. Worth re-evaluating now given how much of `dos.library`/`exec.library`/`utility.library` has since been implemented -- may be more valuable now as a systematic audit tool than it would have been earlier.
Related note (3.1-compatibility)
AROS's SFDs track AROS's own evolving API, a superset of -- and in places diverging past -- genuine Kickstart/Workbench 3.1 (V40). LVO/register facts pulled from AROS should be treated as candidates to cross-check against 3.1-era documentation (NDK 3.1 Autodocs, RKRM) where a call's signature might have changed since V40, not assumed correct as-is. This `since`-field work would make that cross-check systematic rather than ad hoc.