Versioning and changelogs for mod authors: version numbers that mean something, where to write them, and keeping old versions

24 Oct 2026 · 3 min read · ModsDrop

Pictured: Nissan Silvia S13 – 8 Configurations and Tuning Options, from the ModsDrop library.

“Which version do you have?” is the first question in half of all mod support threads, and too often neither the user nor the author can answer it. A consistent version number, written in the right places, and a short changelog solve that permanently. Here is a system that works for a single car or a hundred-file map project.

A version number that means something

Borrow the idea of semantic versioning and adapt it: MAJOR.MINOR.PATCH.

PATCH (1.2.3): fixes only. A texture corrected, a typo in a configuration name, a light that pointed the wrong way. Safe for everyone to update.
MINOR (1.3.0): new content that does not break anything. New configurations, a new body kit, a new skin. Existing saves and setups keep working.
MAJOR (2.0.0): something that breaks compatibility. A rebuilt model that scrambles old skins, a map change that needs a new savegame, removed parts that saved configurations used.

The point is the promise each number makes. A user who sees 1.2.3 → 1.2.4 updates without a second thought; one who sees 1.x → 2.0 reads the changelog first.

Write it inside the mod

The archive’s file name gets lost when users rename it; the version inside the files survives.

ETS2 / ATS: the package_version field in manifest.sii, which the Mod Manager shows.
FS25: the version element in modDesc.xml, shown in the mod selection screen.
BeamNG: the information blocks of your JBeam files and the vehicle’s info file, plus your description.
All games: the description and the changelog.

And in the file name

Include the version in the published archive’s name where the game allows it: my_truck_v1.3.0.scs, FS25_myTractor_v1_3_0.zip (Farming Simulator 25 rejects dots and spaces in some positions and requires plain names, so use underscores there). A user with three versions in their downloads folder can then tell them apart without opening them.

A changelog people read

Newest first, dated, a line per change, the tested game version on each release:

1.3.0 – 24 Oct 2026 – tested on BeamNG 0.40.3
- New: Touring body with 6 configurations
- Fixed: rear lights not working on the facelift
- Changed: exhaust sound volume lowered

1.2.4 – 10 Oct 2026 – tested on 0.39.4
- Fixed: missing interior texture on the base trim

Mark anything that requires action in capitals at the top of that entry: NEW SAVEGAME REQUIRED, REMOVE THE OLD VERSION FIRST, REQUIRES 1.62. Those are the lines people need and miss.

Keep old versions

Keep every released archive, named by version, with its SHA-256. When a bug report arrives, you can reproduce it with exactly the file the user has. When a game update breaks the newest version, you can tell users which older version still works on the older game. And when a dispute about authorship arises, a dated history of your own releases is the best evidence you have.

Game versions are not mod versions

Keep them separate. “v1.62” as a mod version for “works on ETS2 1.62” confuses everyone when the mod itself changes and the game does not, or the reverse. Your version is your version; the game version is a note on each release: “tested on 1.62 open beta”.

When the game updates and your mod does not

Add a line to the description, dated: “Still works on 0.40.3 (24 Oct)”. No new version is needed for that, and it answers the question every visitor has on patch week. If the mod is broken on the new game version and a fix is coming, say that too; silence reads as abandonment.

On ModsDrop

Each upload is a file with its own page, size and SHA-256. When you release a new version, describe what changed in the description, and keep the version number in the title or first line so visitors know what they are getting. The description guide covers the rest, and handling bug reports covers what to do when the questions start arriving.