Add Jekyll 3.3 release post #5442
Conversation
| front matter, and it will simply be copied over like a static asset. Neat, | ||
| huh? | ||
|
|
||
| See our [documentation on the subject](/docs/assets#assets-directory) for |
There was a problem hiding this comment.
@parkr Didn't you mean to point to /docs/themes/#assets instead?
| As always, thanks to our many contributors who contributed countless hours | ||
| of their free time to making this release happen: | ||
|
|
||
| !! TODO: Add list of contributors for this release! |
There was a problem hiding this comment.
Here is the list returned by git shortlog da0b45..HEAD -s:
Parker Moore, Ashwin Maroli, Frank Taillandier, Jussi Kinnula, Jordon Bedwell, David Zhang, Florian Thomas, XhmikosR, Anthony Gaudino, Pat Hawks, mertkahyaoglu, Jeff Kolesky, Jonathan Thornton, Nadjib Amar, Nicolas Hoizey, Manmeet Gill, Zlatan Vasović, Anatoliy Yastreb, vohedge, Antonio, Ben Balter, Charles Horn, Chris Finazzo, Eduardo Bouças, Edward Thomson, Gerardo, Júnior Messias, Kyle O'Brien, Mark H. Wilkinson, Mertcan Gökgöz, Michal Švácha, Mike Kasberg, Nicolas Porcel, Patrick Marsceill, Stephen Checkoway, Stuart Kent, shingo-nakanishi
There was a problem hiding this comment.
Thanks! Gonna generate this once all the PR's are in.
| categories: [release] | ||
| --- | ||
|
|
||
| We have tons of new features for you in our latest release of Jekyll. Three |
There was a problem hiding this comment.
Personal nit, I prefer to write from the user's perspective "here's what you can use" more than our perspective "we have lots of features for you".
There was a problem hiding this comment.
+1 for this, and good observation, Ben.
There was a problem hiding this comment.
I can't get anything to sound good. This is the best I got:
There are tons of great new quality-of-life features you can use in 3.3. Three key things you might want to give a whirl:
There was a problem hiding this comment.
That sounds fine to me! Though I might replace 'give a whirl' with just 'try'. But that's the tech writer in me talking. :)
| to use a theme that was packaged as a gem. Due to security necessities and | ||
| ease-of-use concerns, this initial ship only included support for includes, | ||
| layouts, and sass partials. A theme couldn't write any CSS, JavaScript, or | ||
| content to your site. |
There was a problem hiding this comment.
- Was it really security? I thought it was just us being iterative and getting something out the door to nail the basics before adding additional features.
- I don't know what we need to spend the entire first paragraph of the post talking about what users used to not be able to do. Let's get to what they can do faster. e.g., "Back in 3.2 we shipped themes... we're adding to that today with..."
- I like the human tone, but does the reader really care if we're stoked?
| In an effort to make theme management a bit easier, any files you put into | ||
| `/assets` in your theme will be read in as though they were part of the | ||
| user's site. This means you can ship SCSS and CoffeeScript, images and | ||
| webfonts, JSON and other data. Same rules apply here as in a Jekyll site: |
There was a problem hiding this comment.
JSON and other data
I don't know that we want to plant that seed. Themes should be about packaging presentation not content (that's what the site is for).
| user's site. This means you can ship SCSS and CoffeeScript, images and | ||
| webfonts, JSON and other data. Same rules apply here as in a Jekyll site: | ||
| if it has YAML front matter, it will be converted and renderd. No YAML | ||
| front matter, and it will simply be copied over like a static asset. Neat, |
There was a problem hiding this comment.
Do you want to mention that this is only true if it doesn't already exist in the site?
|
|
||
| Want a clean way to prepend the `baseurl` or `url` in your config? These | ||
| new filters have you covered. When working locally, if you set your | ||
| `baseurl` to match your deployment environment, say `baseurl: "/myproject"`, |
There was a problem hiding this comment.
Do we want to use the opportunity to explain how baseurl should be used? I can see lots of users using this filter and setting their baseurl to / as a result.
| `url: http://localhost:4000`. When you are developing locally, `site.url` | ||
| will yield `http://localhost:4000`. | ||
|
|
||
| Note that this only applies when `JEKYLL_ENV` is equal to `development`. If |
There was a problem hiding this comment.
What if JEKYLL_ENV isn't set?
There was a problem hiding this comment.
Isn't JEKYLL_ENV set to developmentby default?
| `/assets` in your theme will be read in as though they were part of the | ||
| user's site. This means you can ship SCSS and CoffeeScript, images and | ||
| webfonts, JSON and other data. Same rules apply here as in a Jekyll site: | ||
| if it has YAML front matter, it will be converted and renderd. No YAML |
There was a problem hiding this comment.
I'm not a native english speaker, but isn't it rendered ?
There was a problem hiding this comment.
yes @Crunch09, it should be rendered Nice catch!
|
@parkr, can I ask you to add a section about |
|
Jekyll 3.3.0.pre.rc1 does not seem to be backwards compatible to me..
Correct me, if I'm wrong, but I think Jekyll 3.3 should actually be Jekyll 4 echoing @pathawks' comment. |
FWIW the change which caused this error is not part of the public API so i didn't think it would cause any issues. That said, another option would be to revert this: #5451 (comment) |
|
|
||
| Note that if a user has a file of the same path, the theme content will not | ||
| be included in the site, i.e. a user's `/assets/main.scss` will be written | ||
| instead of a theme's `/assets/main.scss`. It's |
There was a problem hiding this comment.
what do think about L28 saying be included in the site, i.e. a user's /assets/main.scss will be read and processed instead?
L29 seems incomplete.. ends with a It's
|
@jekyllbot: merge +site |
@jekyll/core @jekyll/documentation @benbalter – for review.
history.mdand fix link so it points to v3.3 release notes specifically/cc #5400