KazWolfe
commented
1 year ago First and foremost, the actual FFXIVClientStructs project is under the control of aers, and I don't think we have any right to codify policy around it, because such policy may or may not be in line with their wishes and other users of that codebase. The best we can do is discuss the Goatcorp fork, which seems to have been abandoned in favor of just tracking the HEAD of the mainline repo anyways.
While I like this idea in theory, I'm unsure of how exactly this would work in practice.
Let's take an example of RaptureHotbarModule::HotBarSlot and all of its currently-named UNK_0xNN members. If we were to do a rename pass of these to include newly-revealed information, we'd be changing the API in such a way that would facilitate an API level bump. This change would require us to do one of two things on our end: we either ship the "new" version in parallel with the old version until such time as we decide to increment the minimum CS version, or we don't include the change on our track until we're okay with breaking the CS API.
A similar problem occurs with pure additions. If we don't consider pure additions to be "breaking changes", we'd need to ensure they're shipped to all API versions we currently have available or push another API bump for them specifically. The former adds a lot of work on our end to maintaining and verifying everything works properly (and more critically, ensuring that everything remains consistent) while the latter may significantly delay certain additions being available to all plugins within the Client Structs space.
Client Structs is, by nature, a representation of what we know about an evolving and constantly-changing game. A lot of systems remain consistent, sure, but new systems are added and pieces of older systems are discovered and revised all the time. If the game itself changes in such a way that requires us to break Client Structs, then we have no choice but to bump anyways.
In all honesty, I'm not really sure there's that much value in us performing versioning save for rare edge cases. Plugin developers should (see #52) generally provide a best effort to keep things as up to date as reasonably possible, and Client Structs breakages (when they happen) tend to be relatively loud and easy to spot/repair. If a plugin developer really needs to ensure that their plugin remains working through Client Structs changes or bumps, I'd advise they maintain their own fork/submodule at a specific known commit rather than piggyback off of what is currently shipped in Dalamud. It's something we can look at, but I have to ask to what end and who would benefit from such a thing and whether it's worth the associated burdens. The game changes, ClientStructs will change, plugins need to be able to adapt to those.
So they can more easily be merged into dalamud without worrying about breaking changes. You could then force a minimum cs api level when incrementing the dalamud api level.