Releases pages link and (optionally) forward to latest versions

[stockholmux]

Description

Release pages provide a stable URL to point to a version of the software. For example, /download/releases/v7-2-5/ will always have things like the GitHub tag, release date, and artifact links.

In the past, there has been situations where we've made a major release, found a bug, and did a fast-followed with a patch release to fix it. However, the blog post for that release still points to the release page for the original release, obscuring a bug fix. This has two issues:

1. Release pages don't hint at a newer release being available.
2. There isn't a way to link to a newer release in the same line (patch/minor) (e.g. [BUG] No way to link to a latest patch #428) or to the latest major release

This PR adds a few things around this problem:

Release pages have an Available updates section.

On each release page, there is section that advises about updates/upgrades, linking to the release pages for each.

The script only shows the relevant updates for each version. As an example, 7.2.11 doesn't show 8.x releases, only the latest major:

On pages which don't have any updates, the section isn't present.

URL hash and forwards

To directly fix #428, this PR adds an optional hash tag to the URL. If you add #latest_patch, #latest_minor or #latest_major to any release page (e.g. /download/releases/v7-2-5/) it will do a javascript forward to the respective latest version. For example:

• /download/releases/v7-2-5/#latest_patch -> /download/releases/v7-2-11/
• /download/releases/v8-0-0/#latest_minor -> /download/releases/v8-1-5/
• /download/releases/v8-1-5/#latest_major -> /download/releases/v9-0-1/

If there isn't new latest for the different hash tags, it's a noop: /download/releases/v9-0-1/#latest_patch does nothing. So, for release blogs, we can safely use URLs like download/releases/v9-0-0/#latest_patch and users will automatically get the latest patch version. No more obscured releases!

Release candidates are excluded from this logic.

Bug fixes

In writing this feature, I noticed a bug where the multiple releases fragments on the same page (such as on the homepage or /downloads/) misreported the release date for all releases as the first listed. 🤦‍♂️ This is a subtle bug because this often but not always the case.

I additionally tested what 10.0.0 would look like and discovered that, in some context 10.0.0 appeared in the wrong order. Now it's explicitly uses date sorting - the most recent & version numbers are used and 10.0.0 will come out on top.

Refactoring

I moved the release fragment from being a zola include to being a macro. This isolates the scope better to prevent the release date bug as above and actually makes the code a little cleaner.

Issues Resolved

#428

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.