Yeah I understand. But it would've been helpful if there were notes on the relevant pages about how groups tend to work the other way around.
Wrt backwards compatibility, couldn't they just allow both methods? Or would that potentially cause a problem? Personally, I think if something has been deprecated for a specified time, 5 or 10 years maybe, then it should be removed. I get that many people use old skins, but how hard is it to change? And how many come here asking how to fix old skins anyway?! Even complex suites really would mostly need search and replace. It's all well and good keeping things backward compatible, but when things get improved, you're basically keeping inferior code for no reason.
Don't want to get into a tussle here, just want to forestall any discussion about removing our insistence on "backwards compatibility" for any and all changes we make to Rainmeter code. This is a non-negotiable core tenet of our development philosophy, and won't change.
Yes, if it is deemed important enough, we might consider have dual approaches to protect BWC while effecting a change, like we did when we deprecated !Execute and such, but we will NEVER make a change that damages our user's investment in the many, many thousands of skins that have been created and distributed for Rainmeter.
Our goal, successful so far, is that a skin written for Rainmeter 1.0 will work fine with the latest version of the software.
jsmorley wrote: ↑September 25th, 2024, 11:33 am
Our goal, successful so far, is that a skin written for Rainmeter 1.0 will work fine with the latest version of the software.
Good point. Completely understand and I fully support this approach. I say this is the best approach on this kind of apps, which have to maintain compatibility with previous versions.
