SIG.
Member
Unity has "long term support," or LTS, releases. For example, right now, 2019.4 LTS is the stable release. What this means is that new features will not be added to the LTS release, but big fixes will be back-ported into it. New features instead go into the newer 2020.x releases. People can use these releases knowing that certain of the new features may change, sometimes significantly depending on the particular feature-set and its designation (some are "experimental," etc.).
Right now? I really wish GMS had something similar. As a mobile dev, I want basic bug fixes and platform updates. I don't care about the new features at all; I'm never making anything in GMS again, I'm just stuck with it for maintenance right now. But if I want the mobile platform updates, I'm forced to update both the IDE and runner to 2.3, which have a lot of bugs. Some of those bugs have workarounds, some don't, and the mystery 2.3 bug(s) crashing my game are going to steal a lot of time figuring out whether and how they can be worked around, and whether it's better for me to try to work with 2.3 or else figure out how to manually graft the new iOS requirements onto my 2.2.5 build. (And, of course, even if I bite the bullet with 2.3 right now and can make my game work again, there's a whole new universe of potential bugs injected by the new 2.3 features.)
YYG thought they could get around this by making things modular, but that hasn't worked out. The IDE and runner were supposed to be separate, but we've had at least two forced, linked updates. YYG somehow intended to separate the IDE and runner for GMS2 while also baking GML functionality directly into the IDE. Mobile packages were supposed to be at least somewhat separate, but they're not. Basic export functionality has always been hardwired into both the IDE and runner. The IAP updates required updating the runner and rewriting the entire IAP system, as well as importing a new package. (I'm really not clear why they couldn't make the updates behind the scenes and map the existing API onto it. Someone's making an asset to streamline into a single API, seems obvious YYG should have.)
I don't think only mobile devs could use this. I expect that many people with a complex project that's past the initial stages of development would choose stability over new features.
Right now? I really wish GMS had something similar. As a mobile dev, I want basic bug fixes and platform updates. I don't care about the new features at all; I'm never making anything in GMS again, I'm just stuck with it for maintenance right now. But if I want the mobile platform updates, I'm forced to update both the IDE and runner to 2.3, which have a lot of bugs. Some of those bugs have workarounds, some don't, and the mystery 2.3 bug(s) crashing my game are going to steal a lot of time figuring out whether and how they can be worked around, and whether it's better for me to try to work with 2.3 or else figure out how to manually graft the new iOS requirements onto my 2.2.5 build. (And, of course, even if I bite the bullet with 2.3 right now and can make my game work again, there's a whole new universe of potential bugs injected by the new 2.3 features.)
YYG thought they could get around this by making things modular, but that hasn't worked out. The IDE and runner were supposed to be separate, but we've had at least two forced, linked updates. YYG somehow intended to separate the IDE and runner for GMS2 while also baking GML functionality directly into the IDE. Mobile packages were supposed to be at least somewhat separate, but they're not. Basic export functionality has always been hardwired into both the IDE and runner. The IAP updates required updating the runner and rewriting the entire IAP system, as well as importing a new package. (I'm really not clear why they couldn't make the updates behind the scenes and map the existing API onto it. Someone's making an asset to streamline into a single API, seems obvious YYG should have.)
I don't think only mobile devs could use this. I expect that many people with a complex project that's past the initial stages of development would choose stability over new features.