nchlswhttkr / hugo-compress

Compress media files as a build step when using Hugo

G'day, I'm Nicholas! 👋

I'm a developer with a love for web development and automation.

At the moment, I'm helping organise logistics with the awesome crew at UNIHACK.

You can read posts about my interests on my blog or via my RSS feed. I tend to write about music, weekend projects and short technical dives into the software I use.

When I'm not coding, I'm likely playing brass/piano or at band rehearsal! 🎵 🎵 🎵

---

If you'd like reach me, you can find me on the following places. My email is on the sidebar to the left!

Website • Twitter • LinkedIn

hugo-compress's Issues

Versioning releases

I can push images to the GitHub Docker Registry, which I'm going to try out. I can use these releases when building my site with GitHub Pages.

The main question is how to set up a versioning strategy. I've weighed up a few options.

A basic approach would be to only use a latest image. Each change to the Dockerfile/build script pushes a new image to this tag. The only way to go back to an earlier version is to build and push a new image. I'm also not keen to maintain the logic around releasing minor and major versions.

Semver is another approach, and would help avoid breaking changes impacting long-term users. A breaking change would most likely be caused by Hugo itself, or if this build started accepting arguments/environment variables. Breaking changes are still hard to predict though, which leads me to the last one.

Versioning by Hugo itself seems to strike a good balance. It means there can be a release history, and ties it to a Hugo release, which itself follows semver. This should be easier to maintain than semver itself. A latest tag can still be used as well.

The last option seems most suitable to me, though I'd like to be able to bump versions for new releases of other dependencies (programs used in compression). Going by this, Git SHAs is what I'll go with