api4: std.SetFrameProp no longer supports deleting frame property

[AkarinVS]

I understand that api4 have introduced std.RemoveFrameProps dedicated for this purpose, but I think removing delete support from std.SetFrameProp breaks backword compatibility for no good reason and makes writing portable scripts that work with both api3 and api4 VS unnecessarily harder than it should be.

What's the rationale behind this backward incompatible change?

Thanks.

[myrsloik]

Mostly that having a function that both sets and deletes gets a really convoluted argument list and isn't intuitive at all.

[AkarinVS]

But we already have new clearer APIs that separates these two aspects. For compatibility with existing scripts, why not keep the existing APIs unchanged to have a smooth transition? (Intuitive or not, existing users already know how to use those APIs and a new release shouldn't simply break those scripts without any deprecation warnings.) Otherwise, there is no simple way (i.e. not involving two code paths) to write a script that works with both R54 and R55.

[AkarinVS]

The compatibility of releases is important. As is, you can't have a script that removes frame props working in both R54 and R55 without conditional code. And there are code that must work across multiple versions, e.g. mvsfunc: vxzms/mvsfunc@ca51948 Regrettably, it already contains some conditional code to deal with past API incompatibilities, but the good news is that most of them are for way older releases. We managed to keep recent VS releases compatible enough that most people don't even realize there used to be incompatible changes on the API. This is such a simple case: the original API is not broken, just not intuitive and users have come to depend on them. If we think the newer alternatives are better, we can certainly advertise new APIs to gradually phase out existing users. But breaking those existing code is not the most effective way forward. Could we please make R55 more compatible with R54? (You might think changing the script to use R55 is acceptable, but in my experience that makes persuading users to switch significantly harder.)