Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.1] Redirect to current version of Release Support Timeline #10165

Open
wants to merge 1 commit into
base: 4.1
Choose a base branch
from

Conversation

tetrapod00
Copy link
Contributor

As mentioned in #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 tetrapod00 changed the title Redirect to current version of Release Support Timeline [4.1] Redirect to current version of Release Support Timeline Oct 29, 2024
@tetrapod00
Copy link
Contributor Author

CI is failing due to unrelated linter checks.

@mhilbrunner
Copy link
Member

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
Copy link
Contributor Author

tetrapod00 commented Oct 30, 2024

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 #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.

@tetrapod00 tetrapod00 added enhancement discussion area:about Issues and PRs related to the About section of the documentation and other general articles labels Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:about Issues and PRs related to the About section of the documentation and other general articles discussion enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants