search

The-Egg-Corp / CSync

Configuration syncing library for BepInEx.
https://thunderstore.io/c/lethal-company/p/Owen3H/CSync/
Other
1 stars 0 forks source link

New incompatibility introduced, not certain who's side this falls on. #1

Closed Roobotics closed 6 months ago

Roobotics commented 6 months ago

The Mod 'YippeeKeyMod' and 'LethalMeltdown' both suggest Csync 1.0.7 but worked fine on Csync 1.0.8

2.0.0 however I've already discovered a problematic behavior has popped up.

With a fresh Mod profile and only YippeeKeyMod and allowing CSync to update to latest when prompted to 2.0.0

Once the player is on the ship, you can no longer leave via the exit menu, took a bit to narrow down, but this is barebones reproducible.

Unsure who this falls upon to investigate! But I'll have to stay at 1.0.8 to keep known things working.

https://thunderstore.io/c/lethal-company/p/Quadmesh/YippeeKeyMod/

Owen3H commented 6 months ago

Likely that you are experiencing the same issue as #2

Roobotics commented 6 months ago

Yes, that sounds exactly like what I am experiencing, so same issue, unfortunately I couldn't provide console as mine spams me about shadders due to an otherwise irrelevant issue.

Breaking compatibility in this way is going to confuse a lot of folks, all the mod managers just ask you to blindly update to latest for ALL mods. If the features are so much better that compatibility breaks, you might want to consider leaving 1.0.8 as a legacy and opening a new item for 2.0.0? any authors that aren't updating actively will break, and when any mods start requiring 2.0.0 then the thunderstore and R2modman will only let you pick one version for obvious reasons.

I suppose what I'm getting at: Is breaking compatibility like that wise? When the managers all prompt the user to blindly update to latest immediately after 1.0.8 is installed, many mods currently will only function properly with the old variant, yet it will keep trying to over-write it with a now incompatible version.

It makes sense from a programming and developer standpoint, while making only one mod, I totally get that. But is a bad user experience that 'updating' like it suggests, breaks things because it's not backwards compatible. End user's won't know this, it took me a while to realize why things in a 100+ pack suddenly broke as well, thankfully I did briefly notice what I'd let it update, and started working backwards.

Anyways feel free to mark this as a duplicate issue, but I hope what I've said makes sense! I mean it all in the most respectful way I can, but just stating it will cause frustrations in how it gets handled downstream after release, not your fault either mind you, just how the thunderstore ecosystem works with updates, at current.

Owen3H commented 6 months ago

The reality is there is nothing I could've done to prevent this, CSync ideally should've launched with the reduced boilerplate from v2 but it wasn't possible for a while unfortunately. I'm not quite sure what you mean by making v1.0.8 'legacy' but making another mod would just further confuse things and I wouldn't be able to use the same name.

All devs updating will be a good thing in the long run. If they don't want the hassle of updating, a dependency probably isn't for them.

I get that users will blindly update and be confused, but this is what semantic versioning is for. There is definitely a case to be made for Thunderstore/r2modman to warn/inform users and provide devs more ways to mitigate these issues.

Roobotics commented 6 months ago

I think you have a valid point, pulling in external dependencies is fraught with peril if the makers of those mods don't really upkeep them after the fact with any regularity. I also very much agree that mod managers need to let you know you're not on the recommended version of a dependency anymore, for sanity's sake at the very least.

Owen3H commented 6 months ago

I have deprecated all v1 versions on NuGet. Should help make devs aware that they should update.