App Reviews

flocsy🤠 said:

And actually I would be happy if I was able to view my crash reports from ERA Viewer for all versions

Same.

It's funny that there's a comment defending the current behaviour of the ERA viewer (that you can only see crashes from the current version), because the person who wrote the comment fixes all known bugs before releasing a new version.

I guess you're out of luck if:

- you need to release an emergency bugfix version to fix one very serious bug as soon as possible. (Garmin has released emergency bugfix firmware releases, like the release they put out to fix the cold water shutdown issue for Fenix 8. It was obviously an emergency production release, because the fix was made on beta firmware, but instead of following the normal production firmware release schedule, they immediately released production firmware where the changelog consisted of that single fix)

- you just don't have time to fix all the bugs every release (Garmin never fixes *all* the bugs in every firmware release)

- you actually do fix all the *known* bugs and release a new version, but unfortunately someone is still using an old version and experiences a crash (which you won't be notified of)

The same post also says that previous ERA reports will be lost if an app is auto-migrated. So even if you're a perfect dev who fixes all known bugs on every release, and you're lucky enough that nobody running an old version ever experiences a crash, that won't save you from losing unaddressed reports due to auto-migration.

Then the same post goes on to say that old ERA reports are mostly useless because they refer to old source code. As if source control hasn't existed since the 1960s.

FlowState said:

Then the same post goes on to say that old ERA reports are mostly useless because they refer to old source code. As if source control hasn't existed since the 1960s.

Yes, source control worked great for the decks of cards I used to program in the 70's  Until I was bumped and dropped the deck!

Would it help if the average rating displayed for an app was calculated separately for the current version and for all versions? That's not a comprehensive solution, but it's one step in the right direction. We already offer the ability to show reviews for just the current version and all versions.

Not sure, but wouldn't it make it too easy to do an update to eliminate bad reviews even if the problems weren't really fixed?

I think that's a bad solution. I'm not even sure I understand what would that mean.

Either there would be 2 different numbers that would surely confuse the users but probably also most developers. Or there would be only 1 number displayed, but then which one? Let's say the latest version's is displayed. Then this would cause the average to be jumping all over after releasing a new version. Probably this would be also abused by some devs...

It doesn't matter IMHO what are the averages for different versions, because the only thing that matters is the number that the user sees in the listings or the main screen of the app. When I search for something and I need to pick an app I either pick the 1st one in the list *) or one with highest average rating.

*) and then I also assume that this average rating plays some role in the ordering of the search results...

Why do we want to keep the review of an old version by the same user? What value does it have?

Either it's a bad review and the user deleted the app and doesn't use it any more, and there's nothing we can do (similar to current situation).

Or it's a bad review, but the dev fixed the bug, the user tested the new version and... hopefully changed it to a good review. But even if not, the old review (which in this case acted as a bug report or feature request) became outdated and irrelevant to any new user, because they'll only be able to install the latest version anyway.

Or it's a good review. In this case implementing my recommendation would be a disadvantage to the developer, because either the same user could give a worse review in a later version (but that also means this user is actively using the app and "communicating" via the review system, so the bad review still can be fixed later) or they could give another good review (I have a user that gives me a good review in every version, and I have no idea who he is), but in the new system that would only count once in the average.

Contrary to the proposal of counting the average only from the latest version's ratings my idea would still use all the ratings from the old versions. Bad reviews from users gone are kept forever. But there's a chance to mitigate the issue and replace it with a better review if the user is still around.

It would have another good side effect: developers giving 5 star reviews after every version would be able to do it only once.

jim_m_58 said:

Yes, source control worked great for the decks of cards I used to program in the 70's  Until I was bumped and dropped the deck!

??? I have no idea what this is supposed to mean. I get that it's supposed to be funny, but the joke went over my head.

So do you not use source control now? Have you never used it in any decade past the 1970s, for either personal or professional work? Have you never wanted to roll back a project to a previous version to investigate a problem? Never wanted to see exactly what was changed since the last release?

Even the company I worked for which was stuck 10-20 years in the past used source control. Regular backups of the codebase and the source control repository were also made.

My point is that it's a red herring to say that old ERA reports are useless because devs may not have the source code anymore. My point is devs should have access to old source code for their projects, and if they don't, that's kind of a problem. It's a problem that source control was specifically created to address.

Any amateur or professional programmer working on anything they care about even a little should be either using source control, or failing that, backing up their code on every release (this alternative, sans source control, is not something you will see in many professional environments). Obviously using source control and backing up the source control repo is the preferred approach.

The only excuse for not preserving older copies of source is if you're just starting out as a coder, or just messing around with some tiny projects for personal use. But again, anyone who works on anything they care about even a little bit (other than the simplest projects) would be well advised to use source control (or at the very least, to take regular backups, especially when software is released).

I guess you never used a key punch machine to write code, as I did in the 70's!

You claimed source control has been around since the 60's.....

Anyway back on topic, without delving into the complexities and nuances, my initial preference would be:

one user one app one review - which can be updated by the user any time.

I think the dev can respond to bad reviews with 'thanks for letting us know we have now fixed this in version x.x.x'

Which then makes me think (slightly off topic) that bad reviews (1 or 2 stars) should be made to have a comment - to give the dev an opportunity to report it or respond to it - This also "helps" Garmin appear to have a positive store and care about feedback -  I won't hold my breath on this though