Release notes and semantic versioning

Decide the bump

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.
• MAJOR (1.x -> 2.0.0): you broke something the buyer has wired into. A renamed or removed Config key, a changed export signature (different arguments or return), a required SQL migration, a dependency swap (for example moving from a deprecated MySQL wrapper to oxmysql). Their current config or database no longer works as-is.

The test for MAJOR: would a buyer who drops in your new files and restarts get errors or silent breakage with their existing config and database? If yes, it is a MAJOR bump and it needs a migration note.

Write a short changelog

Group your lines under headings. The Keep a Changelog standard categories are Added, Changed, Deprecated, Removed, Fixed, and Security. Breaking changes do not get their own standard category, so call them out loudly at the top, a bold Breaking line above the rest, because that is the one thing a buyer must read before updating. One line each.

## 2.0.0
Breaking: config key `cooldown` renamed to `cooldownMs` - update your config.
Breaking: requires the new SQL migration in /sql/2.0.0.sql before first start.
Added: support for Qbox alongside ESX Legacy and QBCore.
Fixed: dupe when spamming the use key.

Tag the release

In your project folder, in a terminal (Windows PowerShell or a Linux/macOS shell), tag the current commit and push the tag with: git tag -a v2.0.0 -m "v2.0.0" and then git push origin v2.0.0. Here v2.0.0 is the version with a leading v (the common Git tag convention) and origin is the default name Git gives your GitHub remote. Then on github.com open your repository, click Releases (right sidebar), then Draft a new release, pick the v2.0.0 tag you just pushed under Choose a tag, paste your changelog into the description, and click Publish release. What you should see: a release page at github.com/<you>/<repo>/releases/tag/v2.0.0 with your notes and an auto-generated Source code (zip) download. The tag pins this exact commit, so a buyer can download v2.0.0 as a zip, or drop back to v1.9.4 if your update breaks their live server. That rollback is the safety net: when a server owner takes your update mid-session and it errors, they need to revert to a known-good version in seconds, not dig through commit history while players sit in a broken city.

Announce with the migration note

When you ship a MAJOR, tell buyers exactly what they must change: which config keys moved, which SQL file to run, which dependency to install first. A breaking update with no migration note is how you earn refunds and bad reviews. Pin the migration note above the download so nobody misses it.