Release 0.62.0

content/en/news/0.62.0-relnotes/index.md

@@ -1,12 +1,12 @@
 
 ---
 date: 2019-12-23
-title: "0.62.0"
-description: "0.62.0"
+title: "Hugo Christmas Edition!"
+description: "Hugo 0.62 brings Markdown Render Hooks. And it's faster!"
 categories: ["Releases"]
 ---
 
-	From all of us to all of you, a **very Merry Christmas** -- and Hugo `0.56.0`! This version brings [Markdown Render Hooks](https://gohugo.io/getting-started/configuration-markup/#markdown-render-hooks). This gives you full control over how links and images in Markdown are rendered without using any shortcodes. With this, you can get Markdown links that work on both GitHub and Hugo, resize images etc. It is a very long sought after feature, that has been hard to tackle until we got [Goldmark](https://github.com/yuin/goldmark/), the new Markdown engine, by [@yuin](https://github.com/yuin). When you read up on this new feature in the documentation, also note the new [.RenderString](https://gohugo.io/renderstring/) method on `Page`.
+From all of us to all of you, a **very Merry Christmas** -- and Hugo `0.62.0`! This version brings [Markdown Render Hooks](https://gohugo.io/getting-started/configuration-markup/#markdown-render-hooks). This gives you full control over how links and images in Markdown are rendered without using any shortcodes. With this, you can get Markdown links that work on both GitHub and Hugo, resize images etc. It is a very long sought after feature, that has been hard to tackle until we got [Goldmark](https://github.com/yuin/goldmark/), the new Markdown engine, by [@yuin](https://github.com/yuin). When you read up on this new feature in the documentation, also note the new [.RenderString](https://gohugo.io/renderstring/) method on `Page`.
 
 Adding these render hooks also had the nice side effect of making Hugo **faster and more memory** effective. We could have just added this feature on top of what we got, getting it to work. But you like Hugo's fast builds, you love instant browser-refreshes on change. So we had to take a step back and redesign how we detect "what changed?" for templates referenced from content files, either directly or indirectly. And by doing that we greatly simplified how we handle all the templates. Which accidentally makes this version  **the fastest to date**. It's not an "every site will be much faster" statement. This depends. Sites with many languages and/or many templates will benefit more from this. We have benchmarks with site-building showing about 15% improvement in build speed and memory efficiency.
 

netlify.toml

@@ -1,9 +1,9 @@
-[build]
+[build]1.0
 publish = "public"
 command = "hugo --gc --minify"
 
 [context.production.environment]
-HUGO_VERSION = "0.61.0"
+HUGO_VERSION = "0.62.0"
 HUGO_ENV = "production"
 HUGO_ENABLEGITINFO = "true"
 
@@ -11,20 +11,20 @@ HUGO_ENABLEGITINFO = "true"
 command = "hugo --gc --minify --enableGitInfo"
 
 [context.split1.environment]
-HUGO_VERSION = "0.61.0"
+HUGO_VERSION = "0.62.0"
 HUGO_ENV = "production"
 
 [context.deploy-preview]
 command = "hugo --gc --minify --buildFuture -b $DEPLOY_PRIME_URL"
 
 [context.deploy-preview.environment]
-HUGO_VERSION = "0.61.0"
+HUGO_VERSION = "0.62.0"
 
 [context.branch-deploy]
 command = "hugo --gc --minify -b $DEPLOY_PRIME_URL"
 
 [context.branch-deploy.environment]
-HUGO_VERSION = "0.61.0"
+HUGO_VERSION = "0.62.0"
 
 [context.next.environment]
 HUGO_ENABLEGITINFO = "true"