Breaking changes and better mod support

[remyroy]

It would be nice if broken mods could automatically be disabled before they can be used.

One of the issue that happens frequently is people installing mods that are not compatible with the game they are playing. They start their game, enable that incompatible mod and they end up seeing a bunch of debug messages, asking for support and creating issues that need to be filtered out taking time that could be used for something more productive.

One solution to this would be to have some kind of mod API versioning and force mods to state which version of the API they support. When a new breaking change is introduced, the mod API version is bumped and mods that do not support the new version are automatically disabled. The mod API version could also be more granular than a single value. You could have a value for mapgen JSON format, one for LUA methods, one for monsters JSON format, one for item JSON format, etc. A mod that does not need mapgen would simply avoid stating which version of mapgen he needs and could still work if there is a mapgen breaking change. A mod that does not state which version of mapgen he needs would not be given the right to create mapgen in this example.

Potential issues

• After upgrading the game with a breaking change, a player tries to load a game where preexisting mods are no longer working and not updated. The game cannot be played anymore because of missing items or missing code from the missing mod.

This can be related to the fact that there are no regular stable releases where in most other projects are the points where breaking changes are introduced. In many of those other projects, mods are simply stating which main stable release version they support and that solves this issue.

The can also be related to the recent desire to move mods development away from the main game.

Let me know what you think.

[patternoia]

I've been thinking about implementing this mod version management in-game.
Do we want this?

[illi-kun]

Regular stable releases is the best way to achieve the discussed idea.

[patternoia]

This brings us to sensitive topic of having stable tagged and lettered release (like next 0.D) every now and then. Say every month or two.
This is by it self an issue since we had no stable release since 1.5 years.

[mugling]

Regular stable releases is the best way to achieve the discussed idea.

Yes, the current rolling-release is horrible for both developers and users. We urgently need to update a lot of our development practices in this respect.

[BrettDong]

Regular stable releases is the best way to achieve the discussed idea.

Many modders around me have the same idea. They complains about the frequent change of JSON API and no stable release for them to write the mod upon. They feel very depressed when they see the mod they laboured couldn't used by a new experimental version, and what's more they basically have no idea about the API change. They need to know the new JSON API, but there's no information source for them to study. I think we need to change our rolling-release scheme to periodical stable releases. And maybe we need to prepare for 0.D release.

[mugling]

The recent split of content into packs is significant - we are moving towards the possibility of an engine with a versioned JSON API.

[Coolthulhu]

I'm pushing for that 0.D stable, but I don't see many others pushing the necessary fixes.
Going stable implies slowing down with features and fixing bugs.

We might need someone to actually make the decision to get on with that feature freeze. Or possibly "soft freeze" and only block new feature PRs, but still merge or close all the ones on the queue.

[mugling]

We don't need an all-or-nothing once a year release. Fortnightly stables would be a reasonable interim goal.

[Coolthulhu]

1 per ~1.5 month would be the lowest sane period for mod support.

[mugling]

1 per ~1.5 month would be the lowest sane period for mod support.

We don't have to break the JSON API every release

[kevingranade]

On Nov 22, 2016 6:06 AM, "mugling" ***@***.***> wrote: > > 1 per ~1.5 month would be the lowest sane period for mod support. We don't have to break the JSON API every release

Yes, but you do have a system in place to handle it if you do, and I strongly suspect that across most reasonable release periods (down to monthly), we will make some kind of change to the API. I think you are massively underestimating the overhead involved in maintaining a versioned data API, and the value it would provide. If you're considering supporting old versions for 2 months, it would be far more reasonable to just bump a master json version number every time there is a change to any json handling code, and provide old builds for that time period. Then people using mods that depend on old behavior can just use a slightly out of date experimental. If they want an older version it's pretty straightforward for someone (us or them) to archive those versions. The decision to support mods in the repository was very intentional, it sidesteps this entire issue, if you want a mod to work on the latest version of the game, it must be in the repository so developers can see and fix use cases as the code evolves. If you keep your mod outside the repository, you are implicitly targeting an old version of the codebase, but that means your users need to run an old version of the game. The original idea for this was for these to be stable releases, but obviously the current stable release is too old to fill this need, so we either need more frequent stable releases or some intermediate point release. An infinite backlog of daily build would also suffice, but that encounters technical issues around exe sizes.