Spread the word.
If you keep publishing new releases that quick, I run out of superlatives. Again, tnx to @bep and the whole team of contributors! You rock!
The main reason the releases have been a string of pearls lately is that I want to get the image and resource API right … it is less painful to change stuff now that it is not in widespread use.
The Snap & 3rd-Party Releases
Snap Package - the Hugo Snap (Snapcraft) package for Linux distributions - updated
Docker/CI Image - a Hugo Docker image for Continuous Integration- updated
Fedora Copr - Hugo RPM packages for Fedora and CentOS - updated
Brew Package - Hugo package for the macOS package manager - updated
Thank you. I’m looking forward to trying this eventually.
Brew PR has been merged.
I was expecing a drop in performance but no …
| EN | PT
+------------------+------+------+
Pages | 2503 | 50
Paginator pages | 755 | 3
Non-page files | 2528 | 524
Static files | 139 | 139
Processed images | 2933 | 6
Aliases | 410 | 11
Sitemaps | 2 | 1
Cleaned | 1493 | 1493
Total in 30915 ms
For the record, without the smartcrop, the blog took the same time to build. Altough, for some reason, the first trial I did took about 10 minutes.
We cache the image processing result into /resources/_gen and reuse it on rebuild. Which is why I recommend to commit that folder to Git etc.
I was careful with the wording “Processed images” – we handle 2933 “Processed images”, but it is not processed every time.
The image processing part is expensive (with and without the smart crop), and doing that 3000 times on every build would not have worked.
Thx again. Its awesome
COPR updated !
@bep Is there a roadmap for future work on the resource pipeline? Absolutely loving the changes so far and am curious to see what’s on the way.
Not a road map, per se, but I think that once I get done with https://github.com/gohugoio/hugo/issues/4381 then it should be clearer.
That kind of completes the overall Resource
design – and it introduces some other resource types that needs similar handling the images (they needs to be processed in an effective manner).
What that processing means I’m not sure about. But I guess I will introduce some kind of general sha1
fingerprinting, which seems to be a common requirement.
$cssLink := .Fingerprint.RelPermalink
This “lazy way” of doing this is a very easy mental model for me. Both as a user, but also on the implementation side. I’m not just talking about “getting it to work”, it also has to play ball with partial rebuilds etc. . And be “Hugo fast”.
The closest thing we have to a roadmap is Github Milestones. The delivery dates on the milestones are usually met, but an issue being in a milestone doesn’t guarantee that it will be delivered with that milestone.