Upgrade everything

[thatandromeda]

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.

[phette23]

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

[phette23]

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]

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]

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]

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

[thatandromeda]

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]

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.