Why? As mentioned above, there is no reason to "upgrade"--rules will continue to work and remain editable, no matter the version. If you have a need for a new feature in Rule 5.1, then...well, you'd have to re-write the rule anyway, since that feature didn't exist before. This would really help only if it happens to be all features that were not changed compared to a previous version (the only reason they change the app "version"/name, by the way--they've added new features in the past under existing versions where it doesn't break something that is already there), and in that case, there is really no reason besides the OCD you mention. 
2 Likes
I'm not making a functionality argument, i completely agree that it is functional to break a release and run two versions of a language at the same time.
However its not the most user friendly way of doing it.
Here I am making a user friendliness point rather than a functionality point:
A) By making systems backwards compatible the implementer does not need to keep track of which version included a specific feature and can instead focus their energy on the implementation knowing that all up to date features exists.
B) older piece of software can be enhanced with newer functionality without requiring a rewrite into the new IDE. Thus avoid the risk of introducing bugs due to typos or other errors from a manual transcription to the new version.
I would not mind a bit more user friendliness, even if it requires me to do something manual to port my automations to the new framework. I was hoping for something better than just hand typing. even copy and paste between windows would be tolerable.
i don't feel so strongly about this that i want to have a long winded debate about the pros and cons as i find those threads quickly become very unconstructive. i did want to share my perspective and thoughts so it could be incorporated into future considerations.
What a crap show. I muddled my way through the horrible, terrible, no-good garbage dump that RM4 was and created a few involved rules a couple of years go. Haven't touched it since, because this UI is absolutely the worst thing I've ever dealt with.
Now I want to make a small change to one of the rules (extending a delay by 30 seconds), and any attempt to edit the actions results in an error.
There is no upgrade path to RM5, except dealing with the same ill-conceived UI to recreate the rules.
Guys, you lost the plot.
Gotcha, zero support for a product we paid for. Noted.
You seem angry and youāre misinterpreting old posts by staff.
If youād like help troubleshooting, please create a new thread to describe the problem.
Perhaps take a minute to calm down first.
2 Likes
Can't support based on no information. But if you would post the rule in question, and the error in the logs, we can see what's going on. There is support for our product, just not an implementation of a conversion utility from RM4 to Rule 5.1, that the community voted against us putting effort into.
It's worth mentioning a couple of other things: you could be getting this error due to a corrupted rule. You could do a database backup, soft reset, restore from backup sequence to see if this fixes it. If not, it may be possible for me to look at its export file (from App Status page) to see if it is something easily fixed. But, the starting point has to be what I mentioned above, a screenshot of the rule and its logs when it throws the error, from a Logs tab.
6 Likes
