Tenemos 5 actualizaciones en los ultimos 40 dias todas llamadas estables pero en realidad hemos tenido diferentes problemas en cada una de ellas, porque no tomarse un poco mas de tiempo antes de llamarlas estables y probarlas bien, habemos personas que trabajamos todos los dias con los equipos y esto complica los trabajos
Please keep discussions in English so everyone can follow. Feel to use the non-English parts of the forum as well.
We have 5 updates in the last 40 days all stable calls but in reality we have had different problems in each of them, why not take a little more time before calling them stable and testing them well, we have people who work every day with the equipment and this complicates the work.
As I stated in the other thread, unless the update states an improvement in an area that you are having an issue, the update is not “required” unless you are setting up from scratch. Once you have them running, it is up to the owner if they update or not.
A roll back feature would be nice though, in case one run into a bug of unknown consequence.
But then again, there is Emlid`s flashtool which bring you back.
The frequency of our major stable updates is around a few months. We test the functionality and gather feedback from our users working on the Beta version during this time.
The minor releases that happen in between backport new things that are essential for the future major release. That’s why these versions require less time to test and are released quickly.
Andres @andresruzu, I see you mention different issues with each update. We’ll need to get more details about them. Most of the time, the issues cease to be firmware-related and have more configurational background. To tell it apart, we need to understand your step-by-step actions and what behavior didn’t match your expectations. Please get in touch with us at email@example.com so that we can resolve your issues.
Talking about the rollback to the stable firmware version, it’s possible only from the current Beta to the current Stable. We’re not planning to introduce the support of rollback from the current Stable to the previous Stable. Such rollback prevents you from working with the latest features and fixes.
[Edited] Deleted incorrect information about the upcoming feature.
May I suggest the approach of many software vendors etc, where you you 3 tiers of stability: long term stable, normal, and bleeding edge.
The industries of users of GNSS are usually very conservative, and requiring extreme stability, and applying a “if it ain’t broken, don’t fix it”-approach to everything that works as it should.
Adopting a such approach to releases would satisfy most users, as they have a choice.
Thanks for the detailed workflow! It’s a quite popular idea, as I can see from the likes.
We already have pretty much all the stages of this concept. Bleeding edge is the Beta version of our firmware. This is a new wave of features if you want to try them first.
Our Stable releases combine what you identified as Normal and Long Term Stable. That’s the release that goes out with the updates and improvements only after methodical testing.
You can stay on the previous versions of the firmware. There’s still a risk in it: the firmware updates not only bring new features but also build a basis for ReachView 3. So to keep our app full of useful features, we need to update the firmware for the receivers. So with the Long Term update approach, you’ll be inevitably missing out on the latest fixes and new add-ons.
We’ve heard you, though. We’re keeping the updating system as it is for now. But we’ll definitely talk through your suggestion. Thanks!
From reading some of frustration from other users, I think this is the meat of the matter.
There should be a distinct difference between Normal and Long Term Stable. A release labelled Long Term Stable (LTS) is only labelled as such when it has in fact been proven by time (and thus extensive real-world usage (thus not beta-users) from users). We are talking months, not weeks in regards to time-frame.
Users of LTS-releases are happy with the feature set of that particular release, and thus don’t need the additional features and added value from the Normal-tier. They prioritize stability and predictability (extreme “if aint broken don’t fix it”-approach) over new features and the respective code-changes, that inherently bring risk to any software or hardware.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.