Long term support architecture about documentation HOT 1 CLOSED

For software libraries, and apis, I've seen drop-down's to choose major versions that effectively support people working with different versions.

That's fine for single "things" that have specific versions, and a documentation release to go with that version. But the Raspberry Pi documentation isn't around a single piece of software or hardware. It isn't necessarily versioned. OS releases can sometimes make major changes to the documentation, but there are other factors like hardware releases, or the introduction of entirely new classes of product, that change things more fundamentally.

Documentation is not on a per-model basis. It never has been. These days it would be hard to really define what "a model" is when we now have multiple core product lines.

As a consequence we would have to maintain multiple versions (snapshots) of the documentation site, and I don't see that reducing support burden. Especially as these snapshots would be taken at more or less arbitrary places, with documentation for some products okay, while for others the documentation wouldn't be in a good state. It's really unclear to me what would spawn a new snapshot of the site that had to be maintained, versus a change (or set of changes) that wouldn't.

Right now if you want a previous revision of the documentation site you can check it out from Github, and build the site locally. As many users would find that difficult I'm currently toying with methods to automate that, and let users do it inside Github Codespaces, so that they could revert to previous versions of the site automagically, and have it all "just work" in the browser.

Right now effort is going towards rewriting the current documentation (aka Project Rewrite) around the idea that there is more than one core product — most of the mess is there because we had a single product and the design of the documentation is around supporting that and only that — in a more narrative style, with a better split between feature and task-led documentation.

Alongside this we have developer effort is currently directed towards our PDF toolchain which needs overhauled due to technical debt building up, and some fragility introduced by third-party dependencies. After that ships there are other things already on the schedule.

Then maybe after that, we can think about archival revisions. Sorry.

from documentation.