Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)

A suggestion for improved modding stability: Bugfix releases between stables.

(1/4) > >>

EatThePath:
OR: More stable stables through more stables

Over the last couple months it's become increasingly clear that some things have slipped through the cracks that make the last couple stables not so stable for some prominent mods, to the point where they can't be made to work on a recent version without significant redevelopment on the mod's part. That leaves those mods either waiting multiple months for the next stable and hoping that this one will work, or having to resort to running on a nightly. Nightlies both make for a lot of modder work hunting through versions to find one that's good, and open the door for further versioning headaches. Failing that, modders are left with throwing in the towel and giving up.

I'm not trying to point any fingers about this. FSO is a big beast and the mods built against it are highly varied. Some of these breaks aren't obvious right away. But it's put a lot of strain on modders, in some cases evidently and understandably intolerable amounts. Continuing on as always and just hoping the next stables live up to the name seems unwise, to me.

To my mind the solution most likely to actually make things better is to establish a procedure for minor-version bugfix releases. If a mod identifies an issue that is keeping them from using the stable and a fix for that issue is developed, make a maintenance branch off the last stable release with that fix and that fix alone(or as little else as practical as the case may be).

It might be ideal to set some guidelines about...

* How quickly a fix version is to be released after you identify the fix. You'd likely want to give it at least a few days to get some testing, make sure it actually fixes the issue and doesn't create new ones, and incorporate new fixes if other critical issues come up.
* How frequently they can be expected. If a fix version drops and a new critical issue comes out the next day, do you immediately kick in to the process again, or is there a cooldown period to make sure the team doesn't burn out on bug whack-a-mole and has more time to make sure they get it right this time?
I don't know what the optimal answers to these questions are, and situational flexibility would be needed. but I think having established and public answers to them would help set community expectations. It'd also make it clearer when it's appropriate to prod the dev team about something; sometimes life happens and things fall through the cracks, but from the outside it's hard to tell if that's happened or if the wheels of code are just turning slowly.

I'm sure there's considerations here I'm overlooking, but if a good procedure for something like this can be found I think it will help bring down stress levels for everyone a bit in the end.

jg18:
Speaking only for myself and not on SCP's behalf....

I can't speak to how well bugfix releases alone will address long-term mod compatibility issues (for example, Phantom Hoover's concerns here) but I think regular maintenance releases between stable releases could be a good idea.

A more stable engine can make modders (and players) happier, and as the wiki once said, happy modders make more content.

One idea is a temporary maintenance branch between stable releases, like EatThePath suggested, but with all important fixes ported to it (definition of "important" TBD), rather than only a fix for a specific mod. But I understand that including any non-essential fix carries some risk for a mod.

As EatThePath said, waiting a few days after the fix appears in a nightly before porting to the maintenance branch could be a good idea.

To simplify maintenance releases, I suggest a predictable release schedule (monthly?) but I guess a one-off hotfix could be released for a critical issue.

Maybe it's a bad idea, but my $0.02, for whatever it's worth.

At least we're past the not-so-good old days of stable releases occurring once a year (or even less).

Goober5000:
The quarterly release cycle is intended to improve FSO's stability in precisely this way.  We have a mini-code freeze before every release, precisely for the purpose of squashing any outstanding bugs.

It doesn't take much effort to post an official build, but it does take a fair amount of effort to manage the release cycle.  I don't know that we have enough manpower to produce maintenance releases with everything else going on.  PR reviews take a lot of work too, and there are a lot of pull requests currently outstanding that need reviewing.

Cyborg17:
What could work is for newer members to look at bug fixes and see if there are any that should be applied, wait a few nightles to make sure that the bug is really fixed, then just recommends that they be back ported to the stable release.

With the amount of time that I've had, I barely feel like I've been able to do anything, so I know I wouldn't be able to do that.

mjn.mixael:
Not everything that causes compatibility issues is so clearly a bug. I've brought up this example before and at the risk of sounding like a broken record, I'm going to do so again because it's the perfect example of the kind of breakage mods encounter without expecting it. It's also a pretty good example of how SCP handles these types of issues (see: they don't).

BtA had a mission with an event tied to when the AI fires missiles. The idea was that the event would trigger when the AI hostiles get within firing range and actually start firing. There's a thousand ways to FRED such a thing, but this is the way the mission designer chose. This bug did not exist at release or for several years following. Then at some point unknown the AI started firing as soon as they arrive in the mission even though they are out of range of any valid target. This caused the event tied to AI missiles firing to trigger too early, breaking the mission.

It's easy to fix in FRED, which is what I did. But the implications of this small AI change are pretty broad. Outside of just the sexp, this implies that across the board the AI has fundamentally changed when they choose to fire missiles which can have far reaching effects on missions and mission balance. I know SCP is aware of the issue. Asteroth scolded me for months about not fixing the mission in BtA (Notice how he expected me to fix it in the mission even though it's the engine that broke it). Is anyone in SCP even interested in looking at why this behavior changed? I suspect not and that we're just gonna roll with it now.

To be clear. I don't need this fixed. I've already spent many months revamping my old missions to work on newer builds. But this is the kind of stuff that changes frequently enough to be frustrating between stable builds. For mods that are in active development that want to use newer features, there's no way around this. The breakage almost always comes from difficult to debug or otherwise very muddy actions in the engine. The kind of stuff I would be very wary of backporting to anything resembling 'stable'.

And no, this bug is not on GitHub. My last couple of bug reports have gone completely ignored, sooo... ¯\_(ツ)_/¯

Navigation

[0] Message Index

[#] Next page