Module B8 · Ship, sell & maintain

Release notes and semantic versioning

Buyers update with confidence when versions mean something. Semantic versioning (semver) and a short changelog turn "new update lol" into "this is a safe patch" or "this one needs a config change." It is five minutes per release and it kills a whole category of support tickets.

You'll build: A versioned release with a grouped changelog and a GitHub tag a buyer can roll back to.
Time: ~15 minutes.
You need: A script under Git and a place to publish changelogs.
You'll learn: What MAJOR.MINOR.PATCH means -> how each maps to a real FiveM change -> how to write a changelog -> how to tag a release

BEFORE YOU START

Version and document a release

Decide the bump

The version number matches the kind of change.

For a FiveM resource, the bump is not a feeling, it maps to concrete things a buyer's server depends on:

PATCH (1.2.3 -> 1.2.4): you fixed a bug and nothing the buyer touches changes. A fixed dupe exploit, a corrected blip colour, a typo in a notification. Drop in the new files, restart, done.
MINOR (1.2.x -> 1.3.0): you added something optional and the old setup still works untouched. A new optional Config block with a sensible default, a brand new export alongside the existing ones, a new command. A buyer who ignores the new feature notices nothing.

Release notes and semantic versioning

Version and document a release

Decide the bump

Write a short changelog

Tag the release

Announce with the migration note

Keep reading the full lesson