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

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

<< < (4/4)

EatThePath:
So my take on some issues:

On the effort needed to build these point/bugfix release: it is undeniable that this draws resources away from other places and will slow main line development. I’m okay with that. I’m as feature hungry as anyone, but if having more mods working immediately and more modders able to have confidence in being able to use features current or upcoming means slowing the stream of new innovations, I think that’s a net positive for the community. Obviously there’s a tipping point where the tradeoff isn’t worth it, but I think we’re at a point where adjusting priorities towards stability somewhat is appropriate.

On MJN’s point about compatibility issues that aren’t bugs strictly : It’s a grey area, but my view is this that changes to the fundamental behavior of the game that aren’t behind flags are in principle undesirable, and if they can be identified and old gameplay restored that would be suitable for a ‘point release’ especially if the effect is significant. However, it is a case of tradeoffs. Sometimes that change might be a necessary evil that enables some other change, or sometimes the old behavior might be too fragile and hard to quantify that it just can’t be pinned down, or possibly even the change has been in place long enough that you’re breaking things either way. Someone needs to make a judgement call in the end, and I think the biggest help to the community here would be some documentation of the identified or suspected issues like this and the SCP current stance on them.

All in all I think z64555’s summary of the situation and potential plan of action is generally solid and workable. The details of git branching strategy are kind of above my metaphorical pay grade, I haven’t used git for much fancy, so as long as the proper procedure is documented somewhere, whatever works for the team I’m not going to make too much fuss about.

The one thing I’d add is that I think it would probably be wise to have a thread here either for the submission and discussion of potential critical issues, or for the announcement of critical issues that have been identified/submitted with github issues. Either way, the goal is to create a stronger channel of discussion between mod and engine developers, make sure that the issues one side is aware of are known to the other side, and make both side aware of each other’s views on those issues. I’m sure there will be some contention from time to time in such a thread, but it is I think better than people being/feeling in the dark. The exchange in this very thread about the BtA issue highlights how that can increase friction needlessly.

Cyborg17:
Ok, so I think the effort involved in point releases has been really overblown. There's a better way to think about and organize it than what z64555 is suggesting.

Here's what should be done instead:

Rule 1:
Point releases should be limited to fixes already merged in master. This allows two channels for testing and prevents extra coder overhead.

Rule 2:
If an AI bug is found that for some reason really needs to be addressed by a point release, then the SCP needs to decide how to hide that behavior behind a flag so that in fixing one thing we don't break other mods that be that depend on the old behavior. In general those type of AI fixes would be rare, since mods would testing against the AI decisions of that stable version. So fixing the missile launching AI difference that mjn is talking about would be hidden behind a compatibility flag.



The point release cycle should be this process:

1. The SCP creates a new branch based on last stable about half of the time period to the next scheduled stable release.
2. The SCP looks at the bug fixes submitted since the last stable and filters out any that would be suspected of changing AI and balance. Fixes for new features or QOL changes written since the last release would, of course, also be filtered out.
3. Modders are giving the ability to comment on things they would like to see fixed but which aren't addressed via a form thread, GitHub or discord. So if there is an AI or other fix that was filtered out which modders really want, it can be added and put behind a compatibility flag. A list of the approved fixes would be kept on the forum thread.
4. The SCP applies those fixes to the point release branch and puts out a release candidate.
5. The community is given about 2 weeks to try out that build, since they are not the main focus of what the SCP is doing or what modders are doing.. the testing would basically be there to determine if fixing anything change the expected behavior of a mod that depends on that build.
6. Based on testing, either small adjustments are made and another release candidate put out, or the build is released.

Anything more than that is probably over-complicating the task, because the goal is to apply fixes to previous builds so that modders do not have to upgrade their mod to take advantage of fixes.

Besides the startup tasks, like creating a forum thread format, the SCP would only have the only added responsibilities of

1. Filtering already existing, applied and tested bugfixes
2. Creating a build
3. Listening to the community
4. Possibly putting a fix behind an optional flag

z64555:
Ok, from my understanding, your proposal has the following differences from mine:


* Regular cycles halfway between full release cycles instead of as-needed
* Cherry-picks all bugfixes from master, not just critical bugfixes
* Seems to focus on AI and balance-breaking bugs rather than the broader regression category
* Hide broken features behind an opt-in flag instead of removal
* Testing cycle is 2 weeks versus the "standard" 1 week

Some disorganized comments:
Doing a regular cycle every 2 months may be too frequent, would have to test to see how well this holds up.

Cherry-picking all bugfixes from master may prove challenging, especially on merged fixes that have not been squashed.

AI and balance-breaking bugs should of course be a priority, but I feel like it leaves out regressions of existing behavior/bugfixes which can leave modders feel jaded and frustrated.

Hiding broken features behind opt-in "experimental" flags might allow for volunteer testing from other than the dev, which is good.

The 2-week testing period may be too long or too different from our release cycle's 1-week period.  This is more of a habit management issue in that people could inadvertently get used to one or the other and end up disrupting the workflow.  Would have to test over 6 months or so to see how well it turns out.

Navigation

[0] Message Index

[*] Previous page