You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand the reasons outlined in #651 for not automatically upgrading to Jekyll 4.0 along with all the consequent dependencies, among them Liquid and Sass. The problem now is that as all of these projects continue to evolve, it becomes harder and harder to learn what capabilities are natively supported by GH-pages—one has to dig extra hard into any part of the the documentation to discover whether any particular claim is true for a GH-pages site. Consequently, GH-pages becomes harder and harder to use. Ease-of-use is one of the things that has made GH-pages so incredibly popular and powerful over the years, so not paying attention to the erosion of this quality is a threat to the system's continued relevance.
Personally I would prefer if GH would avoid breaking old websites by adding a "legacy jekyll" checkbox to repository configuration—frankly it seems easier than what I'm about to suggest—but failing that, I'd like to see GitHub maintain a site that collects all the documentation for versions of jekyll and the tools on which it's built that are actually supported.
Thanks for your attention.
The text was updated successfully, but these errors were encountered:
"Legacy Jekyll" is practically being used now, as any non-Actions GH Pages builds are today called "Classic", so that gives the idea why the gems probably won't ever get upgraded beyond security-related bumps or minor/patch versions to fix tiny things. #651 (comment), actions/jekyll-build-pages#104 (comment), #651 (comment) …
That should probably be pinned somewhere. TL;DR that reads to me like:
you have a bunch of .MDs a want them published without knowing the SSG/stack? Pages Classic will do that for you.
you tweak the configs, work with anything Jekyll-related locally, can serve/build etc.? Set up Pages via Actions instead, and use whatever you want.
I understand the reasons outlined in #651 for not automatically upgrading to Jekyll 4.0 along with all the consequent dependencies, among them Liquid and Sass. The problem now is that as all of these projects continue to evolve, it becomes harder and harder to learn what capabilities are natively supported by GH-pages—one has to dig extra hard into any part of the the documentation to discover whether any particular claim is true for a GH-pages site. Consequently, GH-pages becomes harder and harder to use. Ease-of-use is one of the things that has made GH-pages so incredibly popular and powerful over the years, so not paying attention to the erosion of this quality is a threat to the system's continued relevance.
Personally I would prefer if GH would avoid breaking old websites by adding a "legacy jekyll" checkbox to repository configuration—frankly it seems easier than what I'm about to suggest—but failing that, I'd like to see GitHub maintain a site that collects all the documentation for versions of jekyll and the tools on which it's built that are actually supported.
Thanks for your attention.
The text was updated successfully, but these errors were encountered: