Maintain backwards compatibility consistently, or don't maintain it at all

[Pustalorc]

After this last update, a critical extension method used by a lot of plugins to determine if their code was running on a separate thread to the game thread was removed.

This was that extension:

    public static bool IsGameThread(this Thread thread) => thread == ThreadUtil.gameThread;

Without this stupidly simple extension, any plugin or library referencing this, now has to update and do the check to ThreadUtil.gameThread manually, which subsequently results in any other plugins or libraries referencing those plugins or libraries that used that also needing to update.

The main purpose of this post is to get you, Nelson, to maintain backwards compatibility consistently, that means this method and any others deleted like it instead get restored and get an [Obsolete] attribute, until eventually you do decide to remove them, and devs have had their warning.
If you do not wish to do this, then please, don't maintain backwards compatibility ever. Remove all [Obsolete] methods, and just add and remove as you wish, without ever maintaining backwards compatibility.

I am aware that knowing when backwards compatibility should be kept is not a simple task and can consume quite a bit of time, but if its too hard or complex to just not delete methods without marking them [Obsolete] first in 2-3 release cycles, then don't uphold backwards compatibility at all.

In summary, I just want consistency. Either backwards compatibility is always upheld, or it is never upheld, not the current situation where sometimes it is, other times it isn't, and devs have to worry about which random important method will soon vanish or be replaced.

[SDGNelson]

Sorry about that. Maintaining backwards compatibility is important to me. For example, I still retain backwards compatibility for plugins calling RPCs the old way.

In this case it looks like I must've removed it without thinking when I was changing something in that file. Usually I have reminders in the method comments along the lines of "plugins use this, don't remove even if it has zero references" but not here. It's restored for the .1 patch and has that comment now.

Unfortunately, despite my best efforts, some updates break plugins. I sympathize with how frustrating this can be: before working on Unturned (a long time ago now!) I also scripted/modded in several games and felt annoyed whenever the developers unintentionally broke my stuff.

[SDGNelson]

Edit: actually it looks like part of the reason is that I changed the class to non-static (which I should revert because maybe that breaks compatibility) and changing to non-static meant removing the extension method, which I then forget to add back. In general I just musn't have been thinking about compatibility at the time.

[DanielWillett]

I agree, and personally, I lean towards not maintaining backward compatibility (at least not as much as you do now). I mean, look at Minecraft. They have breaking updates every few months, and it keeps the modding scene fresh with new content instead of the same plugins being used 4 years later.

Realistically most plugins already break during updates, because almost every major plugin has to patch internal stuff, etc which can break even without a public API change. If it means we get features quicker or changes to fundamental systems that you're locked into I think most people would be able to tolerate API changes now and then.

If more plugins start using OpenMod then it would matter even less because only OpenMod needs to be updated instead of each plugin since everything's abstracted.