Subscribe to issue notifications on GitHub

TLDR: Make sure you subscribe to issue notifications on GitHub.

Hugo’s --minify option is fast, but we couldn’t use it with AMP sites because it caused AMP validation to fail. Instead, we post-processed Hugo’s output with an npm script (html-minifier), but this was quite slow when compared to the --minify option.

There was no need to create an issue on GitHub. Someone else had already taken care of that early this year.

So we moved on, and learned to live with our workaround.

Through a happy accident, this morning I discovered that the issue has been resolved. Excellent, but when did that happen? So I went back through the release notes, and found this in the notes for Hugo 0.70:

Update minify to v2.6.2 01befcce

I read the notes carefully with each release, but this didn’t catch my attention. I did not translate “Update minify to v2.6.2” to “This fixes the problem with CSS minification and AMP validation.”

My first thought was, “We need to change the format of the release notes to include a list of all of the GitHub issues that have been resolved with a given release.” Interesting idea. Who’s going to do it? How much are we going to pay them? How long is it going to take? Would the release notes be too verbose, to the point that nobody reads them? How would we handle 1:N relationships between issues and commits?

My second, better thought was, “Idiot. Why didn’t you subscribe to notifications for this issue on GitHub back in January?”

Learn more about GitHub notifications.

But the above also shows that we should try to create more descriptive notes if possible for the upstream dependency updates. There is usually some more details in the commit message body, but the title is used for release notes.