Release Jekyll v3.2

[parkr]

This is a checklist for releasing v3.2.0.

• Documentation for gem-based themes
• Write jekyll new-theme command ( Add 'jekyll new-theme' command to help users get up and running creating a theme #4848 )
• Port changes from Port changes in v3.1.4 & v3.1.5 & v3.1.6 forward #4911 forward to master branch.
• Fix jekyll new-theme and theme template based on feedback ( Fix more theme things #5042 )
• Convert Jekyll-new theme to a gem-based theme ( Cleaning up site template & theme updates. #4922 )
• Cull list of issues in the milestone & punt where possible
• Test Jekyll against Pathutil to find breakage.
• ThemeBuilder: Remove example site from theme (ThemeBuilder: Remove example site from theme #5141)
• Release 1.0 of minima (Ship 1.0 minima#1)
• Publish release post ( 3.2.0 release post #5140 )
• Release jekyll gem
• Release jekyll-docs for v3.2.0

/cc @jekyll/stability @jekyll/build @jekyll/ecosystem

[envygeeks]

Add Pathutil#cleanpath to that list because we have Pathutil in there now and I need to make sure it's completely backwards compatible.

[benbalter]

Documentation for gem-based themes

https://jekyllrb.com/docs/themes/

[parkr]

https://jekyllrb.com/docs/themes/

HOW DID THAT GET THERE?! 😄

[envygeeks]

@parkr @benbalter that's why I commented that the release of the documentation is part of a much larger issue, every time we update the site the beta documentation lands on there indiscriminately and it's led to quite a few people asking questions about unreleased features and being confused.

[benbalter]

HOW DID THAT GET THERE?!

I wrote them!

[chrisfinazzo]

In cases like this, would it be preferable to ask that changes to documentation land in a separate branch? Currently, everything goes straight to master and sometimes things aren't ready. Whether it gets tagged as beta, or something like {{feature}}-docs-vx where vx is the anticipated milestone for when it should be integrated.

This is probably too formal, curious to hear what @jekyll/documentation thinks.

[envygeeks]

That's actually along the lines almost of what I was thinking. I was thinking that I could talk to @parkr about maybe adjusting the merge bot so he can add an extra flag to merge documentation into the latest stable branch and only release the latest stable branch onto the site, and then we could adjust the domain to do something like beta.jekyllrb.com for master (of which I would happily host if Github Pages can't work that way.)

[erlend-sh]

I like how Ionic has implemented versioned docs in their Jekyll site:

http://ionicframework.com/docs/api/service/$ionicBackdrop/

I can see something like that working very well for jekyllrb.com as well, tough for Jekyll differentiating between "stable" and "beta" (or latest/nightly/dev etc) would probably suffice.

[envygeeks]

@erlend-sh I always liked doing it that way but that might take a ticket of it's own to deal with as it's a decent sized job and would require some restructuring and optimization. I wonder if we couldn't also add documentation via Cucumber.io doesn't it do that same style documentation except through our cucumber files?

[chrisfinazzo]

Has anyone pulled the default theme out to create a gem yet? If not, I'm game.

[ghost]

@chrisfinazzo hi game, i'm dad sure, go ahead

[suriyaa]

👍

[chrisfinazzo]

@jekyll/core Still WIP - need to figure out Rubocop errors - but it's a starting point

[parkr]

@chrisfinazzo I already did most of this! Sorry :/ I forgot to make the repo public.

[chrisfinazzo]

Ack! Please push it when you're ready and integrate/replace as needed.

I want to do a separate gem for my own site (currently working through the nuances of Susy grids), so this wasn't a bad use of 20 minutes.

👋🏻 to @zellwk, his book is a great way to get started with it.

[parkr]

@chrisfinazzo I have the beginnings of it over here: https://github.com/jekyll/minima Finishing up in #4924.

[envygeeks]

Wrong ticket bud.

[parkr]

Merged the last PR for theme stuff.. Off to the races. Going to cull the milestone by this weekend and get this shipped!

[parkr]

Thinking through some last-minute things here:

• Should we upgrade to Rouge 2?
• Should we upgrade to Liquid 4?

Releasing another beta now.

[vaughandroid]

@parkr I don't know about those specific libraries, or how good your test coverage is, but in my experience upgrading libraries is best done at the start of a release cycle rather than the end. Too much risk!

[AndorChen]

Yeah, Rouge 2 changes a lot, but it has a backwards-compatibility solution.

[budparr]

@parkr Aside from any other considerations, but I think there are performance gains in Liquid 4 that would be welcome, and from this conversation it doesn't seem as though it would be a difficult change: Shopify/liquid#678

[benbalter]

Should we upgrade to Rouge 2? Should we upgrade to Liquid 4?

I'm a big proponent of getting 3.2 out the door with its current scope, and then immediately scoping a small 3.3 if we're interested in those major bumps. Minor releases are cheap and we're not on a set schedule, so no harm in getting 3.3 out a month (or less) after 3.2. Fewer moving parts means fewer things that can break.

[parkr]

Thanks for the feedback! Seems small enough to do for a minor release, but should be done for 3.3, not 3.2. 😄

[dalanmiller]

@parkr I'd love to see Rouge 2 because our site uses a lot of Javascript template strings which weren't fixed until recently.

[parkr]

@dalanmiller We're going to have to punt on Rouge 2 until Jekyll 3.3. Too many moving parts. (Integrates into {% highlight %} and into kramdown, so both need to be compatible.) We'll ship 🔜 !

[parkr]

Done!!!!!! 🎉 🎊