Hi Doug,
indeed it is time to adapt that - but the adaptation - for now - will be minimal.
In the most recent discussion we have considered that the main content will always be meant to apply to the latest version. Older versions are still meant to be covered and where differing they should be marked accordingly.
The reality is that maintaining them separately just is an entry to redundancy and all the issues that come with it. And on the other hand the majority of entries does not change often. For those that do it would be something like āNote: in releases before XX.YY ā¦ā.
Example:
Former: āTo achieve foo, do barā
New: āTo achieve foo, do foobar ⦠Note: in releases before XX.YY ā¦ā
That allows to document for example a feature that is added in between LTSes already when it is added. Weād just state that it was not available before XX.YY. And it allows - if it changed how to do things - to outline both versions. The scale of this depends on a case by case decision. For example if on a page 95% stays the same but one aspect is different, then a little Note before a section will do. If on the other hand e.g. handling a particular workload was totally changed (e.g. we changed which program is in main to handle it) then that would more likely be an intro page linking to older/newer content.
If down the road we really have a proliferation of content due to ātoo many versionsā we can think about splitting it, but right now that should result in the best outcome for a rather low effort.
The page already says āUbuntu 20.04 LTS (Focal Fossa) and laterā to reflect that. Iāve found that we also need to change the PDF link to say the same and I should mark the āand laterā just as bold as the rest.