IMO there should be placeholder text explaining that we used to have a service there but it was removed (with a link to this issue), along with some guidance on why sites might wish to keep it around (if at all).

[justinegeffen]

IMO there should be placeholder text explaining that we used to have a service there but it was removed (with a link to this issue), along with some guidance on why sites might wish to keep it around (if at all).

Let's do a favour to future us and any client doing an upgrade to help explain within the manifests why something is different rather than having to answer it one-off via support tickets.

Originally posted by @gwright99 in #843 (review)

[gavinelder]

@justinegeffen what about a docs change log ?

Which can document the changes to the documentation over time rather than adding artifacts across the repo which grow irrelevant over time.

Mentioning that in 25.3 we changed the install guidance to remove a config option feels okay, keeping a reference to historic config option becomes messy because it is unclear when we should remove the now new reference, and these references would continue to grow over time.

[justinegeffen]

An internal docs changelog can definitely be considered but I don't believe there's a benefit in a customer-facing one, mainly because:

• New content is linked from release notes, blogs etc.
• Content that's removed is not removed from past versions so customers can still access it.

That said, it's not a heavy lift (or shouldn't be) to crawl the docs repo and generate a docschangelog.txt file.