Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
Given that usually an update save-compatibility is written in big red text that nobody reads, I find it dubious to posit that a versioning scheme specific to starsector mods would improve anything.Perhaps I stressed too much regarding save-game compatibility. There are some implicit benefits from following SemVer - namely predictability (X something big, Y something new, Z something fixed), stability (X can break, Y can change, Z is same), and quality enforcement (doubly implicit, if you are required to bump major for every breaking change you may feel compelled to make a non-breaking change instead, or provide migration).
Not that having a proper versioning scheme is a bad thing though, it's good. Just not for that purpose.
Going by whether something is save-compatible or not, doesn't really work that well in practice, either. Very minor changes can cause save-incompatibility while you can have massive updates that do not break saves. Save-compatibility is simply tied to very particular specifics and pretty much completely removed from how major an update is.What is a major release? Rewrite? Big new content? It is arbitrary. Under SemVer it only becomes mandatory to increment Major version when breaking compatibility (save game, API, etc) but it is not obligatory to break compatibility in order to increment Major version (you can still increment it if you are releasing something big). With a major update though you are not expected to guarantee backward compatibility.
And indeed it could lead to oddities like incrementing a minor version for a massive update but having to increase the major version for the next hotfix.A hotfix that is mandatory should always be backward compatible. As it usually means adding extra code, it would probably be better to break SemVer rules: release a patch increment (say 1.10.1) that replaces broken release (1.10.0) and consider it backward compatible (like the broken one never existed).
As a modder you no longer need to tell if the release is save-game compatible or not. As a mod user - you no longer need to ask.
Communication is always a good thing. The "no longer need" does not mean you should not. Heck, even if you do mention it multiple times in different posts there will be people asking about it anyway.As a modder you no longer need to tell if the release is save-game compatible or not. As a mod user - you no longer need to ask.
I already talked a bunch about this on the discord but I feel I really need to stress this in a more public space: this is genuinely bad advice. You need to communicate save incompatibility very loudly in the patch, and expecting a user to have additional knowledge to tell that by looking at version is extra extra bad for anyone new to the game.
In general I think that SemVer is simply meant to fix problems that don't really exist in our environment and has requirements that either greatly increasly required work or make this just look silly, nudging you towards warping your workflow around it...True, its purpose is for highly dependant software - mostly to solve GNU Linux dependency hell. I believe it can be successfully used by some mods, thus delivering a benefits and improving those mods (quality, process, etc.).
And sorry for bashing you so much for suggesting it but I really don't want this to make someone end up adopting it, it's just not a good idea for us.I don't feel like being bashed, it's a healthy discussion. I do not agree with generalisation of "SemVer is not good for mods period". Some mods can successfully use it and benefit from using it. For some it will be not be easily applicable.
Perhaps I stressed too much regarding save-game compatibility. There are some implicit benefits from following SemVer - namely predictability (X something big, Y something new, Z something fixed), stability (X can break, Y can change, Z is same), and quality enforcement (doubly implicit, if you are required to bump major for every breaking change you may feel compelled to make a non-breaking change instead, or provide migration).If X is used both for big, but not save breaking updates and for save breaking updates of any size, it kinda loses clarity, since you no longer can tell if a mod is save breaking by looking at X and if any given X update is big. Of course, you can reply that the modder can make a non-breaking change instead or provide migration, but that's expecting a lot of effort and potential future issues for someone who makes mods for free.
Semantic Versioning makes the most sense in a context where you control architecture and users have incentives to learn and consistently apply your versioning. Neither applies to Starsector modding.
If X is used both for big, but not save breaking updates and for save breaking updates of any size, it kinda loses clarity, since you no longer can tell if a mod is save breaking by looking at X and if any given X update is big.It's not something I'd advocate to do, but is possible if you wish. Major updates in well established projects do come with backward incompatibilities (mostly because it's the only window to remove deprecated code). Even in a small codebase like mod, I will use this possibility to remove deprecated code.
Of course, you can reply that the modder can make a non-breaking change instead or provide migration, but that's expecting a lot of effort and potential future issues for someone who makes mods for free.Yet this is exactly what the whole open source does, for free. If your update is save-breaking and you don't want to bother with writing migration code just increase the major version. Even if you use SemVer nobody is forcing you to spend extra effort on user experience (which save compatibility is, ability to enjoy new things in existing save - nice to have, not essential).
Perfectly said.But to do so it needs to understand which update is breaking the save. So if not SemVer, then an equivalent that provides versioning regime will be needed. Alex already did this for mod dependencies - this is the same approach as SemVer:
The failure modes I see constantly:IMO those are the problems we need to fix. It would be great if the launcher could read a Mod's JSON file and saves to figure that stuff out (work for @Alex). It would save everyone a lot of wasted effort.
- Not save compatible
- Not StarSector version compatible
All we need to make our life easier is to extend that to save games (refuse to load game if the major changed)."version":"0.3.2.1",Version of this mod; required. Can also be specified as:"version":{"major":3, "minor":2, "patch":1}A major version mismatch between the mod and another mod that depends on that version of it means the mod that depends on it can not be enabled. A minor/patch mismatch results in a warning.
Perfectly said.But to do so it needs to understand which update is breaking the save. So if not SemVer, then an equivalent that provides versioning regime will be needed. Alex already did this for mod dependencies - this is the same approach as SemVer:
The failure modes I see constantly:IMO those are the problems we need to fix. It would be great if the launcher could read a Mod's JSON file and saves to figure that stuff out (work for @Alex). It would save everyone a lot of wasted effort.
- Not save compatible
- Not StarSector version compatible