Supporting multiple Factorio (Major) versions

[BlueTemplar]

I'm pretty sure that one reason/bonus of the new versioning introduced by 0.18 is to not have minor versions break mod compatibility any more ?
(At least where the API is concerned... can't guarantee this for things like mod game balance !)

(So, for your example, 0.17.35 would have been 0.18 with the new versioning system ?)

[Squelch]

I don't see the value.

I'll take that as a personal judgment and opinion, and not a Wube policy

As a modder myself, the versions for the stable release still work, and if people are playing stable, they can play the last version of the mod that I released for the stable update.

Indeed, the version released for stable will still work, but I for one can't be 100% confident that there isn't an undiscovered bug that might need attention.

For myself, I am updating my mod to experimental, using the new features, fixing bugs I make, improving things,
I do not have any interest in playing in the stable release, I have no interest in backporting things to stable release

That is entirely your prerogative of course. I don't think anyone is advocating that modders are forced to follow any particular release strategy when it comes to their creations. Likewise, I do not think that making assumptions about my users and how they play the game should be prescribed by myself. I'd rather hope that my offerings make their day a little better, and to be as inclusive as possible. Mod combinations that any given player has can be as nuanced as the hardware they play on, so I would like to accommodate as many permutations as possible. Players that are still using 17.79 stable, and even those that have stayed on 0.16 for whatever reason, are included.

I fully understand why it is said that trying to support prior versions is a hassle, and that simply developing for Exp is the path of least resistance for many modders. It rather makes it a fait accompli don't you think? As I said before, stable kind of becomes pointless if Exp has the majority of use and mod support. It would be interesting to know what kind of metrics there are in this regard.

I think a big question is: what does the post-1.0 landscape look like? Will there continue to be major refinements to the game, with potentially game-breaking changes, or are they going to be the more minor sort once official release has passed? If it's the latter, then a multi-version system doesn't make much sense because it's only an issue during pre-release "early access". If it's the former and all mods have to update every 6-12 months, it might be worth considering post-release.

...
So allowing people to prematurely mark both .17 and .18 doesn't necessarily mean the mod will work on the rest of .18. There will likely come a time when an 18.x release makes a mod no longer work with the same code as in .18.0. From the .18.x perspective, the older versions of .18 will be quickly forgotten (relative to the .17 stable), but the mod that works on .17 stable and was marked with .18 compatibility will no longer be actually .18 compatible with the newer stables.

You make some very good points that I have failed to broach so far. Yes, it does entirely pivot around how post 1.0 is handled, and this request/enquiry can be seen as pre-emptive or preparing the ground. Incompatibilities in a point release are a nasty that I hadn't considered, and has already caused some problems as I recall. That would give even more value to a stable release I would think. Regardless, such changes are far reaching, and I'm not sure anything short of a different release strategy from Wube could avoid.

[steinio]

What the Frick.

It's good as it is.
How would you ensure that your mod is compatible to both versions at the same time if prototypes changes in experimental.

You think your idea works because some simple mods need only to change the value in the info.json but that's just coincidence.

Please stop it now and consider the huge value of two separate mods for sperate versions. Github will support you with branches if needed.

My2cents.

[Squelch]

What the Frick.

It's good as it is.
How would you ensure that your mod is compatible to both versions at the same time if prototypes changes in experimental.

They are tracked and advertised on GitHub in case you wasn't aware.

You think your idea works because some simple mods need only to change the value in the info.json but that's just coincidence.

That would be a maverick and stupid thing to do. I'm not sure where you think that is being suggested. Comprehension?

Please stop it now and consider the huge value of two separate mods for sperate versions. Github will support you with branches if needed.

My2cents.

The exact versioning tools or methods any given developer uses are not in question. I'm sure that many of us are familiar with branching, tagging, cherry picking, and merges etc in Git. Creating revisions that support different game versions is not the problem if you care to read the whole thread. It is how those versions are supplied to the players that is the issue at hand.

Anyway, thank you for your kind contribution.

[Hanse00]

What the Frick.

If you're going to disagree with people, at least do it in a respectful manner.
And please understand that different developers work in different ways. Just because this works for you, doesn't mean you should undermine that others may be of a different opinion.

What I and @Hanse00 seem to be seeking, and I'll hazard a guess there may be others, is the ability to support multiple major versions where the codebase is common and unchanged.

I don't see the value.

As a modder myself, the versions for the stable release still work, and if people are playing stable, they can play the last version of the mod that I released for the stable update.

For myself, I am updating my mod to experimental, using the new features, fixing bugs I make, improving things,
I do not have any interest in playing in the stable release, I have no interest in backporting things to stable release

Okay so let's unpack this. I understand that you choose to support the latest experimental, and that works for you. Great!
But I think we need to make room for people who prefer a more stable experience as well.

As Squelch said, some players prefer to stay on stable. I want to support people who only go from 0.16 stable to 0.17 stable, to 0.18 stable as well. As that's a perfectly valid playstyle, it's something I've done myself for most of my factorio career (And if you look in the sidebar, you'll notice I've been doing this for a while).

If I make any updates to my mod during 0.18 experimental, I want those updates available to people playing 0.17 stable (Where feasible, of course if an API change is part of what triggered the mod update, that's a good time to cut a new release of the mod, that only supports the feature going forward).

This all relies on, as others mentioned, API stability. Wube is of course free to follow any versioning scheme you guys want, but I'm personally a fan of SemVer. I'd like to see API backwards compatibility be preserved between any 0.18.x version, until a 0.19.x comes out, at which point you may introduce backwards incompatible changes. As this relates to the above, it means that at the time of 0.18.0, I should be able to test if my mod will require any changes to be compatible with 0.18, in which case I would make a new version, or if I can just bump the factorion_versions number.

But once I know my mod is API compatible with 0.18, I should not need to worry until 0.19 again.

At a higher level, I think this is not only a conversation about supporting multiple factorio versions, but about API stability in general. I feel that the game is maturing to the point, that it's something worth considering.

And let's not forget the history of where factorio came from: Minecraft modding. A scene that has endlessly been plagued by Mojang / Forge changing the APIs between Minecraft versions, driving modders to not support new versions at all. In fact the Minecraft modding scene is consistently multiple major releases behind. I don't think that's where we want factorio to end up. Where all the vanilla players are on 0.20, whilst modders are still playing 0.17.

[justarandomgeek]

How would you ensure that your mod is compatible to both versions at the same time if prototypes changes in experimental.

You think your idea works because some simple mods need only to change the value in the info.json but that's just coincidence.

It would be fairly straightforward in data stage to look at the version string in mods["base"] and create your prototypes accordingly. If the new version is a superset of the old version, you don't even need to check.

Control stage you can look at game.active_mods["base"] to do the same sorts of things, or depending on the change you may be able to just attempt it and let the game ignore you (for new fields in Concept types, for example).

I've also had many mods in past stable/experimental cycles with identical code apart from the factorio_version in info.json, to the point that i used to do releases in pairs!

All that said, I mostly have the same strategy as what Klonan described: I develop on the latest version. I release new features on the latest version. If the latest is experimental, the previous stable version will get bugfixes for game-breaking bugs, but that's it.

[Mengmoshu]

I'm just here to say that I agree backporting anything to versions of a mod intended for earlier versions of the game than my newest mod release just isn't going to happen. I guess there could be a bug serious enough that I might consider publishing a fix, but I'm honestly not bothered by people dropping my mod when they are the ones unwilling to run a newer version of Factorio.

I'm not criticizing anyone for preferring to stick to stable, but I also don't think it's anyone's responsibility to complicate things just to make the experience nicer for people sticking to stable. Players on stable are already not getting new base game content and features, so not getting changes to a mod is just more of the same. And the "benefit" players sticking to stable get is keeping old bugs (though too rare to have been spotted and fixed yet) instead of risking new bugs, and the same is true of mods. That seems like a pretty small cost compared to the potential complexity of maintaining either two versions of your mod or god forbid any number of internal code routes based on the Factorio version.

Furthermore, the strictness of the version support system requires mod makers to open up their code and actually do something whenever a new major version comes out. I think that's a pretty good thing, it can't force anybody to test their mod even enough to prove that they got the syntax right in the info.json, but I think it helps.

P.S. The timescale that both major and minor changes happen on isn't terrible either. I think a lot of people miss the other implications of using the word "stable" to describe a version. It isn't changing, it's known, and you should expect it to be that way for a usefully long amount of time.

[Solinya]

This all relies on, as others mentioned, API stability. Wube is of course free to follow any versioning scheme you guys want, but I'm personally a fan of SemVer. I'd like to see API backwards compatibility be preserved between any 0.18.x version, until a 0.19.x comes out, at which point you may introduce backwards incompatible changes. As this relates to the above, it means that at the time of 0.18.0, I should be able to test if my mod will require any changes to be compatible with 0.18, in which case I would make a new version, or if I can just bump the factorion_versions number.

But once I know my mod is API compatible with 0.18, I should not need to worry until 0.19 again.

I was originally advocating such in my post, then edited it out after further reflection because while that would be nice for modders, it slows down the factorio devs and makes the experimental branch less useful. At least in the pre-1.0 world.

For example, I imagine 0.18.0 was released now to get early feedback on all the graphics and sound changes. But those aren't the only potential "breaking" changes in the pipeline. The GUI rework, the new fluid system (maybe), and anything else I can't think of right now are all possible future improvements that might require mod updates. But if we force only breaking changes in a .0 release, then they'd have to first find a .18.x stable before releasing any new features to experimental. I think that would slow down development during the precise time they're trying to crunch for the 1.0 release.

Post-1.0 is when I'd start to expect more API stability. But again, they need to balance their interests (ability to develop and evolve the game) against those of the modders. Say they release a 1.1.0 experimental and some new system ends up being a horrible idea so they opt to remove it - do they remove it in 1.1.12 experimental when they first make the decision it could be cut, even though some mods might now be depending on that system - or do they have to abandon 1.1.x and jump to 1.2.0? (I suppose any 1.1.0 mods using that new system wouldn't be tagged as both 1.0 and 1.1 though.)

For me, I think this is only an issue around when new branches start. I'm in the middle of developing a new feature for my mod, but if I want to play with it on my IR server, I have to backport to 0.17. But over time, most of my new maps will be started on 0.18 using .18 mods, so .17 takes on less importance. I long stopped playing 0.16, so I don't really care about compatibility there. Thus, we come back to "what does the post-1.0 landscape look like?" because that will indicate how frequently this will be a problem. I don't know if Wube has a definitive answer yet, since focusing on official release is more pressing.

[BlueTemplar]

Again, as a reminder :

Release plans
This week we released version 0.17.79, and marked it stable. Internally we have been calling this 'Stable 3', and the main feature was the new tooltips we showed in FFF-318.

There is one constraint we put on ourselves when we started this more swift feature release schedule: We want to avoid breaking mods. This is easy enough in principle, don't start renaming things, don't remove API features, etc. However as we develop further, there are certain features and improvements that we can't realistically do in a way that won't break mods, such as the new Character GUI (FFF-289), and color correction (FFF-320).

It is for this reason that we are going to accumulate some of these mod breaking changes, and release them all at once. Since it will definitely be breaking mods, we will bump the major version number, so it will be 0.18.0.

We have already internally started merging in these 0.18 features into our master branch, so we will not be doing any more 0.17 releases (unless something absolutely catastrophic is discovered).

To me, this suggests heavily that the next version with mod-breaking changes is going to be 0.19 (which might be =1.0, but since there are still 8 months and 1 day until then, I doubt it).
P.S.: And probably so on, even after 1.0 ?

[Hiladdar]

It is possible to write a mod, that works under several major releases, such as 0.16, 0.17, and 0.18. The alternative is is to write a mod 3 times, once for each release.

At issue, is when there are major changes between releases. Consider the changes to science between version 0.16 and 0.17, or some of the mod braking changes between some of the experimental versions of 0.17.xx.

For this reason, my recommendation is to design and write mods for the current stable / experimental release. Most players will either play on the current stable or current experimental.

Hiladdar

[Honktown]

I have a question from the mod page side - what's the best way to upload the same mod version for different major versions? If I change the zip file name, it will very much error about a name or version mismatch. I could "cheat" and do 1.17.XX and 1.18.XX or something, but I'd rather minimize how much crap I have to do if it is all the same code. The site doesn't add a salt or anything (server-side), so I can't have two versions of the same filename.

edit: wait, it only lets me upload one zipped modfile at a time. Can I have two with the same name for different major versions?

[Squelch]

I have a question from the mod page side - what's the best way to upload the same mod version for different major versions? If I change the zip file name, it will very much error about a name or version mismatch. I could "cheat" and do 1.17.XX and 1.18.XX or something, but I'd rather minimize how much crap I have to do if it is all the same code. The site doesn't add a salt or anything (server-side), so I can't have two versions of the same filename.

edit: wait, it only lets me upload one zipped modfile at a time. Can I have two with the same name for different major versions?

Here's what we have discovered so far.

• Factorio broadly follows SemVer convention, but in the form Main.Major.Minor, not the conventional Major.Minor.Patch more commonly seen. There's no hard and fast rules in this regard.
• The name of the .zip must match exactly with the concatenated mod name and mod version fields in info.json
• "factorio version" field in info.json should be thought of as the target Major version of the game. It is explicit, and the game's executable version determines which mods are listed based on this. [1]
• There is implicit support for different versions of the game according to the rules above, so the same codebase can be loaded according to the mod packages target version alone (within reasonable scope of what calls and prototypes have changed within the game)
• The Mod Portal has issues and behaviours that differ from how the game's modmanager works. ie offering the latest mod version regardless of target version by default. It also has limited space to list more than just a few mod revisions.

As your edit shows, and the whole point of this thread, is that these aspects of mod management seem to be poorly incompletely documented or understood. I have a feeling that the implicit side of multiple game version support might have gone unrecognised because it seems to "just work" and many modders are keeping to the experimental branch anyway.

I do plan to make a complete summary based on what has been discovered and discussed in this thread and edit it into the OP so others may benefit from these findings too.

1

There is an exception to this if config.ini is edited to allow other game versions to be listed. vis:

Code: Select all

; Options: true, false
; use-version-filter-in-install-mods-gui=true

I consider this to be dangerous, and is a hidden setting probably intended for development purposes only. YMMV

[Edits for formatting and unkind assertions]

[Honktown]

...

Thanks for replying. Turns out what I wanted to do does work: I can embed the major version in XX.YY.mynumbers, and the game automatically shows people the proper version. I was worried if I had 1.18 and 1.17, people on .17 would always get the "newest" version - even though it's incompatible. Turns out that no, the mod installer thing does parse which major version the zips are targeting, and only shows the newest one for a specific major release. Except for some minor variations in info and changelog, this'll work for my uses. Easier than making multiple pages or never bugfixing previous versions.

[BlueTemplar]

Welp, looks like I misunderstood what Wube was going for.

Though it makes sense, considering :

Nope, we definitely want [mod declaring to support a specific major version] to be explicit.

[...]

While we will try to avoid it, we aren't going to handicap ourselves right now in experimental by promising not to break anything.

[Squelch]

Thanks for replying. Turns out what I wanted to do does work: I can embed the major version in XX.YY.mynumbers, and the game automatically shows people the proper version.

Excellent!

If this thread does nothing else, then uncovering that fact alone, and sharing it with others makes it worthwhile.

Welp, looks like I misunderstood what Wube was going for.

Though it makes sense, considering :

Nope, we definitely want [mod declaring to support a specific major version] to be explicit.

[...]

While we will try to avoid it, we aren't going to handicap ourselves right now in experimental by promising not to break anything.

Yes it does make perfect sense. Wube have their own priorities, and during the process of realising them, modders and players are going to be in for a tumultuous time. An interesting, and exciting one nonetheless. My spidey senses must have been tingling, and the foresight in trying to nail down the subtleties of the versioning system was the aim. Having a "stable" benchmark version to fall back on will be of the highest value during this time.

I will, and would like to encourage everyone to interact with the 0.18.xx series as much as possible so that the final polish and bugs are honed and reported. I will be running parallel versions, one for pleasure, and one or more with the intention of hopefully adding value to the final product. A certain pleasure is also derived from the latter I might add.