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 …”.

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.

You are absolutely right Doug, last update was at “Generated on 2021-03-03 03:52:43”.

I have to admit I do not know enough about the underlying details … :-/
I’ll get in contact with the web team who owns the machinery that converts one to the other to see what is the problem.

@dsmythies - FYI I have not forgotten this, but the PDF generation is more deeply lost than anyone expected and therefore takes more time than expected to recover, but I’m on it.

after PDF generation being broken for quite a while I have worked with our web team and it is now back on track - with better format and link retention than before - and finally rendered daily again.

This time the server team itself is aware where and how this is done, so I hope it won’t be lost “again” so easily.

As I said with more words before - finally PDF rendering of the server-guide content is back up and working.

Hi @amichai,
for quite a while even PDF generation was broken which is now fixed.
With all the conversion now taking place in a way that the server team has actual control of I have had a look at the epub option.

AFAICS TOC works, internal and external links work, but I’m not an experienced epubuser, so I can’t decide if the output is any good.
Could you give a try and compare it to

Would that be a sufficient option that you’d consider helpful to you and other users?

Would it need to be split in chapter files or anything else that I’m not aware of?