Chad Fernandez
Back to all posts

Posted 3 days ago4 min read

Changelog: Writing stories powered by Hashnode

Changelog: Writing stories powered by Hashnode

This is my first #changelog writeup, yay!

Inspired by the weekly changelog from the folks at Railway (use my referral link to try out Railway), I plan to write more of these updates in the future. They might not be weekly, but I aim for at least once a month.

A blog powered by Hashnode

If you're reading this, it means the blog section of my portfolio is now live. Welcome!

I spent most of the weekend integrating Hashnode and its Headless mode into my portfolio site. It was a refreshing experience, though it came with its own challenges in managing information from an external API source.

If you don't know, Hashnode has a Headless mode that disables the built-in Hashnode frontend for your blog. Instead, you use the Public API to integrate it into your existing website or workflow. In my case, this lets me have my portfolio and blog on the same site, giving me full control over how it looks and functions.

But this is just the beginning. We have many optimizations and changes planned to improve your experience reading these stories and to enhance my experience writing them.

Adding auto versioning to projects with Release-it and GitHub Actions

It has been a week or two of experimenting and testing, and I have finally created my own custom workflow for auto versioning using Release-it and GitHub Actions in my projects. I'm still gradually implementing them, but I'm happy with the results.

I have tried implementing auto versioning in my projects before, but I removed them because they either required too much configuration or I wasn't satisfied with the results. The most common way to version projects is by using semantic versioning (semver), which follows a set of rules for incrementing project versions. The semver format is MAJOR.MINOR.PATCH, and the rules are as follows:

  • Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

  • Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

  • Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

You might think there are already many implementations of auto versioning with semver, and you're right. Release-it solves this problem by default. However, I've made a few modifications in my implementation:

  1. Self-contained workflow: Release-it and its dependencies are installed in the GitHub Actions workflow, so there's no need to run npm i --dev. It also uses caching, so we don't reinstall the dependencies every time the workflow runs if they're available in the cache.

  2. Plug and play: To get started, all you need is the release-it.json and the release.yml GH Actions workflow file. Review it and customize it depending on your needs.

  3. Version bump based on PR labels: One major reason I created this workflow is to control the version bumping behavior using PR labels. Use release: major for a major bump, release: minor for a minor bump, and release: patch for a patch bump. If no bump label is added on merge, it defaults to a patch bump.

It's a bit messy, but @chof64/ex (ex.chadfernandez.me) has more information about this. P.S. I'm still working on improving the documentation for this.

Whats Next

  • I'm starting development on CampusConnect for my capstone project. CampusConnect is a centralized academic management system that includes grading, attendance, and learning modules.

  • We are joining KomsiHack 2025: DemocraTech Hackathon, a coding competition by UPV Komsai.Org, that aims to develop tech-driven solutions that strengthen democratic engagement.

  • Improvements on the design, SEO, and implementation of Hashnode as a CMS in my personal website.

  • Updated documentation for experiments (@chof64/ex) is being planned.