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

Upgrade everything #58

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Upgrade everything #58

wants to merge 3 commits into from

Conversation

thatandromeda
Copy link
Member

Addresses #57 .

Everything is now on its latest available version, except for liquid,
terminal-table, and unicode-display_width, for which Jekyll specifies
lower major versions.

This also updates the .gitignore, since Jekyll now generates a
.jekyll-cache directory.

The README doesn't specify a testing procedure, but I've run jekyll serve locally and clicked on all the navigation menu links and it
looks fine.

This will force any other devs who don't have bundler 2 to install it,
but 2.x has been around since 2018.
GitHub pages supplies it. 🎉
Everything is now on its latest available version, except for liquid,
terminal-table, and unicode-display_width, for which Jekyll specifies
lower major versions.

This also updates the .gitignore, since Jekyll now generates a
.jekyll-cache directory.

The README doesn't specify a testing procedure, but I've run `jekyll
serve` locally and clicked on all the navigation menu links and it
looks fine.
@phette23 phette23 self-requested a review December 3, 2021 22:11
being a diverse and inclusive community, seeking to share ideas and build collaboration.
baseurl: "" # the subpath of your site, e.g. /blog
url: "http://code4lib.org" # the base hostname & protocol for your site, e.g. http://example.com
url: "https://code4lib.org" # the base hostname & protocol for your site, e.g. http://example.com
Copy link
Member

@phette23 phette23 Dec 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the consequence of this. The site loads fine over HTTP on the local dev server and I doubt we have mixed content embedded anywhere. But if something goes haywire after merging maybe take a look at the HTTPS here

Copy link
Member

@phette23 phette23 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! This built fine on my non-M1 Macbook Pro. Specs:

$ uname -a && rbenv --version && ruby --version && gem --version && bundle --version
Darwin MacBook-Pro 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
rbenv 1.2.0
ruby 2.5.7p206 (2019-10-01 revision 67816) [x86_64-darwin20]
RubyGems 2.7.6.2
Bundler version 2.2.29

I intentionally did not update Bundler to the version given in Gemfile.lock (2.2.32) yet it still built fine. I can test other ruby versions if someone thinks it necessary.

@thatandromeda
Copy link
Member Author

Come to think of it, I didn't upgrade the ruby version (I was using 2.7, the oldest fully supported version, but 3.0 is available and 3.1 is in preview). Opinions on whether I should bundle with 3.0?

@phette23
Copy link
Member

phette23 commented Dec 3, 2021

Someone said recently that Jekyll doesn't work with 3.0? I haven't tried. I have no idea what the standard ruby version is these days so I can't answer.

@kaitlinnewson
Copy link
Member

GitHub pages may not work with this version of Jekyll unfortunately.

@thatandromeda
Copy link
Member Author

Good to know about Github Pages compat. I can downgrade to 3.9). I can also stay at 4 and set up a Github Action which auto-deploys it. Pros each below; what do others think?

In favor of 3.9: I kind of prefer the elegance of Pages and don’t like introducing another element to the system, but it would at least be transparent from the POV of subsequent contributors adding to the branch as it would still auto-deploy and people wouldn’t need to understand the process if they didn’t want to.

In favor of 4.0: https://jekyllrb.com/news/2019/08/20/jekyll-4-0-0-released/ Notably, we can use a supported version of sass and handle markdown better. Also, of course, we will be able to continue to upgrade dependencies (the latest versions of many of jekyll's dependencies are not compatible with Jekyll <4.0).

(The markdown handling issue: We get the Github Flavored Markdown parser for free with older versions of Jekyll -- it's included in the markdown processor. And we get it for free with 4.0 -- it's specified as a dependency of the theme. But with Jekyll 3.9, it's not specified in either the latest usable version of the markdown processor or the latest usable version of the theme. This is easy to fix -- just put it in the Gemfile -- but I'm spelling it out here because it took me a moment to figure out.)

@phette23
Copy link
Member

phette23 commented Dec 6, 2021

I'd vote in favor of the simplicity of using Pages with an older version of Jekyll, since we don't necessarily need any of the improvements like speed of processing and the site doesn't use footnotes that I'm aware of. That said, sticking on an older version concerns me for obvious reasons, but I don't think GitHub will let every Pages site break, that would be devastating.

Aside: I forked this repo and the upgrade_everything branch built successfully. You can see the site at https://phette23.github.io/code4lib.github.io/ where some assets are in the wrong place due to the different path, but they were built (main.css, for instance). In the end, it still seems risky to use Jekyll 4.0 when it's not explicitly supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants