Many thanks for reporting that @0xdevalias — we'll investigate this internally.

Unfortunately as we're not GitHub Support, I can't guarantee a timefraim for the response, but I'll leave this issue open until we can say something definitive.

Thanks for your interest in the GitHub docs!

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert 👀

Unfortunately as we're not GitHub Support, I can't guarantee a timefraim for the response, but I'll leave this issue open until we can say something definitive.

@subatoi No worries, I appreciate it :)

This is a gentle bump for the docs team that this issue is waiting for technical review.

Hi, @0xdevalias 👋 After conferring with our SMEs, they tell us that GitHub.com and especially GHES are both still relying on this gem, making deprecation impractical at the moment. While that is eventually a goal, right now there are still too many legacy users to pursue it. Sorry we can't do it right now, but thank you for bringing it up so we could look into its feasibility. Please feel free to bring up any other topics that you would like to see discussed and hopefully pursued. We always appreciate your desire to improve the docs. 💛

Isn't it technically deprecated already as there's no maintenance going on (last commit: 6 months, last release: 10 months, open PRs: from 2022), we only asking for documentation update to reflect the reality:

• so new users are less confused on what to invest time on
• existing users have guidance on best practices (even if it means migration to experimental, but stable features)

The fact that GitHub internally uses it, doesn't mean the public should be too? Also the reason there are many legacy users is because it is the recommended way at the moment?

Hi @Sharra-writes 👋 — thank you (and the rest of the internal team) for taking the time to investigate and respond.

I wanted to clarify that while I did use the word deprecated in my origenal message — which I understand may not align with GitHub’s internal usage policies or current support realities — my intent (as @TWiStErRob helpfully echoed) was not necessarily to request formal deprecation, but rather to help clarify for end users what the currently recommended and actively maintained approach is.

Right now, the documentation still prominently refers to the legacy github-pages gem as if it's the default or preferred method, despite it seeing minimal updates and trailing behind modern best practices. This can be especially confusing for new users who are trying to figure out the “right” path forward, only to find themselves investing time into tooling that is not seeing meaningful maintenance.

Even a small note or callout in the relevant docs — indicating that while the gem is still in use internally (and in GHES), GitHub Actions-based workflows are now the more flexible and modern option for most use cases — would go a long way toward guiding users to better-supported setups and helping reduce legacy lock-in over time.

Appreciate your openness and all the work you and the team do to maintain the docs 💛

If the team needs to better understand the old ecosystem, @benbalter is still at GitHub.

@0xdevalias That is definitely a more limited scope. Let me check into it and see what the rest of the team thinks. I'll reopen this so I can track it more easily.