[4.1] Redirect to current version of Release Support Timeline

[tetrapod00]

As mentioned in https://github.com/godotengine/godot-docs/pull/9929, remove the out of date release support timeline table and replace it with a redirect to an up-to-date version.

That PR mentions redirecting to latest, not stable, but I think stable makes more sense?

I also only removed the single section rather than the whole page. I think it may be worthwhile to keep the rest of the page around as a historical record of what the release policy was at the time of this version. Only the truly out of date release support timline table needs to be fully removed.

Do I need to make two other separate PRs for 4.0 and 3.5 to make this same change on those branches?

[tetrapod00]

CI is failing due to unrelated linter checks.

[mhilbrunner]

Do I need to make two other separate PRs for 4.0 and 3.5 to make this same change on those branches?

The issue is that we again run into this every time we split off a new versions from master, we'd need to remember to do these replacements. And there is also really a larger number of pages that should simply redirect to the latest/master version: the whole contributing section, probably, definitely the release info, etc.

I'd like to take a stab at some semi-automated way to mark pages as "replace this page with a link to the latest version with some description in non-master branches".

[tetrapod00]

It seems like the right long-term solution for the Release Support Timeline might be to host it somewhere else on the website, like Akien mentioned in https://github.com/godotengine/godot-docs/pull/9929. The info on this page inherently becomes out of date very quickly.

Some of the information on this page does feel like it should be in the docs and not on the website, though:

• Overall description of Godot's take on versioning.
• Criteria for breaking compat.
• Which version should I use?
• Ideally, it would be nice if the table could stay on this page, too.

There is slight historical benefit to knowing what the release policy was at the time that a given old version was available. Since 4.x is going to have a long life, the release policy may change wildly from 4.0 to 4.12. But it's only a slight benefit, and the benefits of redirecting the whole page or removing it from the docs may outweigh that.

As for redirecting the contributing section to master for old releases, that makes sense to me if we can do it in an automated way. There is no need to keep it around as historical info. Actually, there is some info in that section that probably should not be careless overwritten, pages like Internal Rendering Architecture. Keeping a historical snapshot of pages like that may be of use to someone remaining on a specific minor version.

Removing a whole page and replacing it with a redirect should be a tool we use more sparingly, I think.