3.0 RELEASE GAMEPLAN

[parkr]

I have written about what I'd like to see for Jekyll 3.0. That post is now a month and a half old. I'd like to get Jekyll 3.0 out the door in Q1 2015 to bring all the amazingness we have been cooking out to you excellent Jekyll users and developers. Check lists usually help me more than anything else, so here's what I'd like to accomplish:

• Incremental regeneration ( Incremental regeneration #3116 )
• Integrate basic hooks (potentially via @imathis's Octopress::Hooks work) ( Add Hooks, based on the Octopress::Hooks project #3392, prototype of jekyll hooks, encapsulated #3553. )
• Switch over to Rouge as default syntax highlighter, dropping hard dependency on Python ( Remove most runtime deps & move to Rouge as default highlighter #3323 )
• Drop hard dependency on ExecJS runtime (e.g. Node) ( Remove most runtime deps & move to Rouge as default highlighter #3323 )
• Make most dependencies optional and handle their absence gracefully ( Remove most runtime deps & move to Rouge as default highlighter #3323 )
• Upgrading to Liquid 3 & adding optional liquid-c support ( Upgrade to Liquid 3.0.0 #3002 )
• Make _posts a default collection (& therefore simplify the internals) ( Make pages and posts instances of Jekyll::Document. #3169, initial implementation of posts as a collection #3690 )
• Remove Convertible.
• Automated Windows tests? ( Add Appveyor testing #3115 )

Anything else you'd like to see?

[imathis]

Everything here looks so great. I'll be especially excited to hooks come to Jekyll. Anything to get rid of all the monkey-patching we do for plugins!

[paulrobertlloyd]

This looks great. In terms of supporting plug-ins, it would be nice-to-have a more fully featured jekyll-paginate be released around the same time (i.e. having the ability to paginate practically any group of posts). Pagination I think is the only area from a templating perspective where Jekyll still suffers slightly.

[pepelsbey]

+1 for pagination issues.

[parkr]

Pagination chat should be had over at: https://github.com/jekyll/jekyll-paginate But thanks for the input.

[IainIsCreative]

Rouge seems like a nice idea, but frankly, I'd like to see if my code blocks can be written out as lists and not using table. Does Rouge support that or are there other methods it provides?

[alfredxing]

👍

We should probably get working on Make _posts a default collection (& therefore simplify the internals) & remove Convertible. Related issue is #3169.

[parkr]

@iainspad If you open an issue on jneen/rouge, I'm sure they can get you sorted. :)

[parkr]

We should probably get working on Make _posts a default collection (& therefore simplify the internals) & remove Convertible. Related issue is #3169.

@alfredxing I was going to wait until @envygeeks landed #3305 his rebase nightmares aren't epic.

[alfredxing]

#3224 (using Liquid::Drop) would also be great if it can be done.

[erlend-sh]

I'm probably just confused by semantics here.

Make _posts a default collection

Does that include Pages as well then?

[parkr]

Does that include Pages as well then?

This is a tougher sell for me – each page is meant to be a separate entity. It therefore doesn't really make sense to join them together into a collection. That being said, we provide site.pages in Liquid, which is a simple array of Page objects. So as it happens we already give the user access to a "list" of pages. Now, whether we want to go one step further and allow all the various add-on features of a collection is not necessarily the case. I'll definitely revisit this once we have a _posts collection to see if we can swing it. :)

[erlend-sh]

I see (sort of). The problem probably lies in my trying to understand Collections through the lens of my pre-existing notions of "Custom Post Types" in WordPress.

[envygeeks]

I thought Wordpress finally had the notion of pages that are actually pages? I've not used it in a few years but I thought back then it did have that concept.

[pathawks]

I thought Wordpress finally had the notion of pages that are actually pages?

Yup.

[felixdorner]

+1 for tags

[kaatt]

How do I use the beta with jekyll-redirect-from plugin?

I get this:

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/specification.rb:2007:in `raise_if_conflicts': Unable to activate jekyll-redirect-from-0.6.2, because jekyll-3.0.0.pre.beta1 conflicts with jekyll (~> 2.0) (Gem::LoadError)

[envygeeks]

@KATT fork the gem you are trying to use and edit the *.gemspec and then tell your Gemfile to use the gem you forked either via :path or :github (if you host it on Github.)

Side Note: Next time please file an individual ticket for your problem.

[nternetinspired]

Anything else you'd like to see?

gh-pages friendly tags!

[kaatt]

Thanks a lot Jordon but still having trouble: #3353

[ivanjuras]

@parkr Is there any chance that we are going to see full Jade support in the near future? it actually saves a lot of time, and makes it so much easier on the eyes. Thanks!

[sondr3]

Given that Jade is a Node templating language and 3.0 is cutting away lots of non-Ruby dependencies I doubt that'll happen.

[cmegown]

The idea of removing non-Ruby dependencies is a big +1 for me. The whole reason I've fallen in love with Jekyll is that I can craft everything (almost) exactly how I want. Part of that is writing code, but another part is also managing the environment in which you write that code. Minimal non-Ruby dependencies will help greatly with that.

[rschwietzke]

Default Less support as well as localization would be high on my list. Especially localization caused quite some headache. We used https://github.com/screeninteraction/jekyll-multiple-languages-plugin but it is not truly part of the concept and has rough edges.

[erlend-sh]

I'm verging off topic here, but @rschwietzke did you try this?
http://www.developmentseed.org/blog/multilingual-jekyll-sites/

It takes the convention over configuration approach. I haven't tested it with collections but I imagine it would be compatible.

[rschwietzke]

@erlend-sh Does not look convincing. I could not find an example, find the explanation a little confusing what to put where. This is another one: https://github.com/drallgood/jekyll-multilingual I guess it is time to ingrate that into Jekyll and find a good concept that covers everything. I am not a Ruby guy, but I could write the spec.

[erlend-sh]

True, it's still a lot to take in. I guess bottom line is I fully agree: standardised localization would be great. It's immensely useful for multi-lingual documentation, which needs to be very self-explanatory since there are so many chefs involved.

[rschwietzke]

@erlend-sh Agreed. Let's make it a 3.1 feature and maybe the only one. It will take Jekyll to the next level and removes the need for a lot of customization.

Shall I write down my conceptual ideas? As mentioned, I am into Java and have my problems with Ruby. Any specific place I should add the requirement ideas to?

[parkr]

Open a separate issue with a list of checkboxes, each one being a requirement. We'll talk about it there.

[parkr]

I've dropped the dependencies and made them all opt-in. We need documentation for that (an upgrading doc!) so people can continue to use all the plugins without too much annoyance. The gem now only includes:

• liquid
• mercenary
• kramdown
• safe_yaml
• colorator
• rouge
• jekyll-sass-converter
• jekyll-watch

which is about half as many gems as before. Yay! Removing pygments.rb dropped the hard dependency on Python, and removing jekyll-coffeescript dropped the hard dependency on NodeJS/ExecJS runtime. This will be part of the second beta, to come out in the coming week.

Working on Hooks now, then we're just about finished!

[migurski]

Quietly watching this from a distance, 👍 to dropping dependencies. Really excited to see 3.0 in the world.

[bcomnes]

Is possible to drop the nokogiri dependance? That thing always throws build errors, not to mention stalls travis-ci for ages.

[envygeeks]

If nokogiri trows build errors I suggest you take it up with upstream.

[parkr]

Is possible to drop the nokogiri dependance? That thing always throws build errors, not to mention stalls travis-ci for ages.

@bcomnes We don't depend upon Nokogiri. Some of our optional plugins do (jemoji, jekyll-mentions), and Travis can be sped up by adding the environment variable NOKOGIRI_USE_SYSTEM_LIBRARIES=true and by enabling the cache (cache: bundler).

[bcomnes]

Can I make note of those tips in the docs?

[parkr]

Can I make note of those tips in the docs?

We mention the nokogiri one here: http://jekyllrb.com/docs/continuous-integration/ but you can include the cache and explain it if you want.

[bcomnes]

Cool, will do.

[rodrigobraga]

Hi guys!

Exists plans to make a official image from Jekyll to Docker?

[parkr]

Exists plans to make a official image from Jekyll to Docker?

Hi @rodrigobraga! No plans as of yet, but @troyswanson might be convinced to maintain something like that. ;)

[rodrigobraga]

:)

I have my own image, but a official image can be a good start point to study, test and make projects based on Jekyll.

I go start use a imagem from @troyswanson

[sondr3]

Hey, quick question, I have a pretty wonky problem that I think has to do with incremental regeneration. I'm currently using the 3.0 beta1 release and whenever I update a post the index file isn't updated along with the post, but the post itself is updated when you visit it. I'm running Jekyll through Gulp so every time I save my posts it runs jekyll build but quite frequently the frontpage isn't updated. Occasionally it'll update however but I can't seem to figure out when it does/doesn't. Any ideas?

[envygeeks]

Please start using unique tickets for your problems, thanks.

[parkr]

Jekyll 3.0.0.beta2 was just released, please go check it out and file bugs as you find them: https://github.com/jekyll/jekyll/releases/tag/v3.0.0.beta2

[envygeeks]

Closing this as all is checked and 3.0 is released.

[jglovier]