Instead of pushing everyone to the new app version then spending 2 weeks slowly updating firmware and breaking a bunch of stuff for people.
Why not roll out the firmware first and then send out a push notification to update the app.
If this works in sure it would stime the number of grumblings about things not working.
Something needs to be done. I would prefer that app updates are fully backwards compatible and firmware updates roll out to a public beta group that is completely 100% open for people to opt into and then after a few weeks of that being successful, then it roll out to everyone (and everyone still have the option NOT to apply it).
To me the obvious solution is to not delete the legacy code in the app and use the correct branch based on the detected firmware version.
I know this is possible… PPVS when it first rolled out actually would not show up on a non-compatible version.
I use Android. I turned off automatic update of the app in Play Store. When the firmware updates, I’ll update the app. Meanwhile the app and the FW stay in sync.
Hi there, thank you — and thanks to everyone here for the discussion.
We understand that the app and firmware being out of sync has caused some inconvenience, and we really appreciate you pointing it out. Your suggestion makes a lot of sense, and we’ll definitely share this feedback with our team for consideration.
Thanks again for helping us improve the experience.
It seems like if it’s a new feature they can hide it easily. It’s when they modify an existing feature it falls apart - No Path Offset until app sees correct firmware.
I’ve written enough software in my career to know you can code around difference in firmware. It’s not easy, and it costs time and money. And if you dont keep going back and cleaning the code you end up trying to support some feature from 1980 that 1% of your users want. At some point things have to change.
Supporting 1 or two “older” versions of firmware in the app should be doable. There are added maintenance costs to the software to make that happen but it is a MUCH better user experience.
In this instance, apparently, support at least 2 older version would work. But maybe you need 3 or 4 depending on release cycle and adoption rates.
1 or 2 even would be better than none.
Couldn’t some sort of software flag be added for minimum app/FW versions and then the app/firmware can read each other and disable/enable functionalities based on what’s available? If something new completely “breaks” either/or… then the update is downloaded but doesn’t install until all prerequisites are met?
I am sure there are probably lots of elegant ways to handle this. That’s on their team to figure out. But it needs to be forwards and backwards compatible. Both firmware and app.
I’d be happy with 1 rev. The firmware is essentially force fed anyway.
If it only supported one rev, we’d still be stuck. I’m still waiting on the firmware update… and need to adjust some maps. But that’s not gonna happen for probably another 3 days if history is any indicator.
Same boat. Spring cleanup always requires some adjustment. Also had the winter to rethink my mapping strategy.
I adjusted an area yesterday with old firmware deleted something. and extended another place
What app version?
The latest. V3.18.2
Hmmm. Now you’re gonna make me try it again. The button was disabled the first time.
Didn’t even see that. What changed?
