Skip to content

Publish per-version doc archives so users on older releases see their own API #8

@SolAstrius

Description

@SolAstrius

The docs site at https://solastrius.github.io/CreateAvionics/ tracks main, so users on a stable release see method signatures for APIs that don't exist in their build yet. Issue #5 is exactly this: user on a pre-v0.3.1 build called setManualTarget, hit "attempt to call field 'setManualTarget' (a nil value)" because the method was documented but unreleased on their version.

What we need:

  • Snapshot the generated docs at every tagged release (v0.3.0, v0.3.1, v0.4.0, …).
  • Serve them at versioned paths (/v0.4.0/, /v0.3.1/, …).
  • Default landing at /latest/ (or just root) showing the most recent stable.
  • Visible version selector in the rendered docs so a confused user can switch back to what they're actually running.

Implementation sketch:

  • The existing GH Pages workflow builds illuaminate output into build/illuaminate. Extend it to publish each tag's build into its own subdirectory.
  • The site's HTML head already includes doc/head.html — add a version selector dropdown there (illuaminate doesn't have a native one, so hand-roll).
  • Workflow trigger: on push to a v* tag, build that ref's docs into gh-pages/<tag>/.
  • On push to main, build into gh-pages/dev/ (separate from latest/).

Out of scope for this issue: per-method @since parsing already exists in cct-javadoc and could power a "Available since v0.3.1" badge inline. That's nice but doesn't help users who land on main-side docs without realising it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:buildGradle, doclet, packaging, CIdocsIncorrect or missing documentationfeatureNew capability requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions