Release management

[davidsneighbour]

How about some form of release management? You could load the API based release info of Hugo (via workflow every x hours) and the installer could, in case I do NOT select a specific version always install/update to the latest available version.

See discussion here: https://discourse.gohugo.io/t/install-hugo-into-your-repository/33564

You can receive up-to-date info about releases from here: https://api.github.com/repos/gohugoio/hugo/releases

I know it's a lot of work, but it probably would make it easier to update Hugo downstream without having to release a tagged version each time Hugo updates.

Included in this proposal/feature request is the ability to "install latest hugo" and maintain the currently up-to-date version of Hugo without brain work.

[dominique-mueller]

So, there are a few ideas floating around here.

One of them is to allow "latest" as the version number (similar to how npm allows it), and perhaps even use "latest" as the default / fallback if no specific version number if specified. My thoughts:

• I am a big fan of always pinning dependencies, using "latest" will for sure break things. Hugo in particular has not yet reached a stable version (e.g. "1.0"), so things could potentially go south with the smallest updates. That's not to say that such a feature should not exist, it's just that I would never recommend using it and therefore begs the question of whether implementing it is worth the effort / trouble some beginner devs might run into.
• From a technical view, getting the information of what specific version actually is the "latest" version requires usage of the GitHub API (as you mentioned). The current implementation, by design, does not use the GitHub API because things like rate limiting. Instead, it relies on asset URLs as exposed by the GitHub frontend. I'm not too comfortable baking GitHub API requests into this library, or authentication methods against it.

Based on the Discourse discussions I understand that keeping Hugo up-to-date is the desired goal, and having "latest" as a configurable version just one idea of solving it. dependabot is great, but of course only supports native npm dependencies and not our own custom ones.

I designed hugo-installer specifically to be independent from Hugo releases, with the exception of situations where the Hugo release format changes (e.g. asset naming, available OS builds). This way, new features (like checksum verification) can be added to hugo-installer, released and then used by devs even if they rely on older versions of Hugo. So, hugo-installer is explicitely not a wrapper around Hugo binaries but a rather generic installer, independent from Hugo releases. Bumping versions numbers of hugo-installer just for new Hugo releases and allowing "latest" as a version feels very much like a workaround to somehow get dependabot working for us.

[dominique-mueller]

The best idea in my mind is to have a custom workflow script within projects that (e.g. every 24h, or based on Hugo GitHub releases)

• looks at the Hugo version defined in the package.json file
• looks up the latest version of Hugo using the GitHub API
• opens a PR with the new version once available

For GitHub, something like this could be packaged into a GitHub action.