Hi,

I am going by the Semantic versioning as outlined here: https://semver.org/

In short, versions are 3 numbers: MAJOR.MINOR.PATCH

E.g. "LostKingdoms-v1.13.15.scx" would be major version 1, minor version 13, patch version 15.

Starcraft map files are only consumed by players and do not have dependencies, e.g. a custom map never depends on other custom maps, unlike actual programming APIs, etc.

So when would you increment the major version of a Starcraft map?

Patch makes a lot of sense--you fixed a bug but otherwise added no new functionality to the map.
Minor is just adding new functionality without breaking existing functionality.

So maybe Major version is used when you fundamentally change triggers or how players used to do stuff.

For example, if I changed the cost of buying a unit by X amount, would this be a major version? Or really just a "balance" version (so maybe it should be MAJOR.MINOR.PATCH.BALANCE or something?). Technically changing costs is a breaking change, because it forces players to revise their strategies...

But, if I removed a spell from the game, or removed access to buildings/units/tech tree, maybe that's a MAJOR version?

But if I add a new spell/inventory system, but all other systems stay the same, wouldn't that be a MINOR version?

Let me know your thoughts.

It's really all just preference. Most of the versions of maps out there don't make any sense. Personally, I'd do a minor increment for every update I do to the map, unless I completely change how the map plays, in which case I might do a major increment.

For small projects where I don't expect more than around a dozen versions, I just go with a single number.

For larger ones, the first is a major feature update where there is a learning curve because so much has changed.
2nd is a minor feature update that at most add a couple of things here and there.
Third is a bugfix release.

The latter seems pretty similar to the semantic versioning.

Removing just a spell/building/unit would be a minor version imo.