In general I agree with this statement, but we have a fairly disjoint set of changes here. Things I change shouldn't affect things jdog changes and vice versa. The downside to frequent merging is frequent merging.
As long as decreasing the frequency doesn't increase the testing required, it will work out.
That's certainly a possibility we could discuss, but I was more suggesting that a general method of designing SDK mods. We already have BAI and the UP being included in other mods, and I suspect the same will happen with BULL. If we all make our changes using #ifdefs, it should be easier for others to maintain merges of several mods and produce multiple versions with the various bits turned on/off as desired.
Instead of merging BULL and BAI, we could keep them separate, convert them both to use #ifdefs, and then collectively create a single merge that contains a bunch of these community mods all rolled into one SDK. We'd develop our own mods individually for easier testing, but we'd produce multiple versions from the combined SDK. This might be a
lot of work, but I think we could streamline the process, combine forces, and save work instead of having each player individually merge their own desired collection.
Imagine having a monthly release of the giant merged SDK that has updates from whichever mods had their own updates that month. Of course, the more mods that get included, the more built DLL versions need to be compiled. Anyone have access to a compile farm?
EIEIO? I've always wanted to think up a name that would work with that acronym.
