View Issue Details

IDProjectCategoryView StatusLast Update
0004591SUMoNew Featurepublic2019-05-21 21:55
ReporterTM123 Assigned ToKyle_Katarn  
PrioritynormalSeverityminorReproducibilityhave not tried
Status acknowledgedResolutionopen 
Target VersionLong term 
Summary0004591: Shown updates if there are several version of the same program installed
DescriptionIf there are several versions of the same program installed then the older version should not inform that there is a major update available.
(see screenshot).
Only minor updates should be reported.


TagsNo tags attached.

Relationships

related to 0005493 acknowledgedKyle_Katarn SUMo Server behaviour if PortableApps.com component SUMo is also detected by SUMo Pro installation 

Activities

TM123

2017-12-19 12:37

reporter  

sumo.png (2,989 bytes)   
sumo.png (2,989 bytes)   

Kyle_Katarn

2017-12-19 21:12

administrator   ~0002738

Are both exe in the same folder ? Are both of them legitimate ?

TM123

2017-12-20 13:53

reporter  

Sumo2.png (7,709 bytes)   
Sumo2.png (7,709 bytes)   

TM123

2017-12-20 13:53

reporter   ~0002741

Different folders (default installation folders):
c:\Program Files (x86)\ABBYY FineReader 12\FineReader.exe
c:\Program Files (x86)\ABBYY FineReader 14\FineReader.exe
And yes - both are legitimate versions.

It looks so whether the Screenshot Reader (as part of Finereader) does not have that problem,

On the next picture you can see different versions of Delphi. The lower versions should show only their upgrade.
Sumo3.png (8,070 bytes)   
Sumo3.png (8,070 bytes)   

TM123

2017-12-20 14:05

reporter   ~0002742

Oh - I had Screenshot Reader version 12.0.101.496 skipped.
After I removed the 'skip update' flag it looks different.

btw. The filename of Screenshot Reader is different in version 12 & 14. So this could be another reason.
Sumo4.png (7,634 bytes)   
Sumo4.png (7,634 bytes)   

Kyle_Katarn

2017-12-23 10:44

administrator   ~0002746

Hello

Thank you for this detailed analysis. Unfortunately, with the current implement of SUMo (both client and server) with only "one" version being active for a Product/company pair will necessarilly lead to such behavior when multiple exe files coexists with the same product/company info BUT different version info, even if legitimate.

Should you have an idea on how to manage this, any suggestion is welcome :)

TM123

2018-03-08 08:30

reporter  

Sumo_Differentversions.png (8,837 bytes)   
Sumo_Differentversions.png (8,837 bytes)   

TM123

2018-03-08 08:30

reporter   ~0002801

I upload a screenshot of another example.
My idea how to handle it (the first problem):
You write that you have only one version active (on server) .
The client knows (or at least can know), that it checked for 3 programs the same "program line" online.
If the newest version is up-to-date then the other ones should not be marked as 'update available'.

Ignoring the program is not a solution - ignoring a specific update also not.
The only way to solve this problem at the moment would mean to exclude the folders. But then I mustn't move them anymore.

wolf

2019-05-16 22:45

reporter   ~0003312

And did you take a look onto SUMo server for such cases of multiple versions detected locally with different file paths?

It happens often that the user flag is missing at SUMo server for tools detected several times on client side.

And several times it happens that among those version detected by the local SUMo installation, SUMo server reports some of them as not existing, providing % and device count only for a subset of versions detected by any SUMo user.

And in such situations of multiple versions detected locally, it happens for some of these tools that SUMo reports the same available update version while for others also proposes different update versions available. This was often the case for ImageMagick which gets released version updates rather frequently. But currently the behavior is more consistent proposing always the same update available.

Kyle_Katarn

2019-05-16 22:53

administrator   ~0003313

This is unfortunately "as per design". I may add an option to only take into account most up to date local version, but in some case it would not make sense. I propose to close without change.

wolf

2019-05-16 23:13

reporter   ~0003316

No, I disagree to close without change. Several users want a change. They still disagree on expected behaviour in the future.

Design decisions may change over time leading to refactorings. So it seems ok to either have it remain in target version long term of open resp. undefined. This issue is categorized as feature request not as bug.

What I still don't understand and consider a bug are those observations where local SUMo client detects tool versions locally and SUMo server declares some of these versions as non-existing.

And is it currently only possible to have none or one version flagged as user at SUMo server side or reflect also several versions as flagged as user version?

Issue History

Date Modified Username Field Change
2017-12-19 12:37 TM123 New Issue
2017-12-19 12:37 TM123 File Added: sumo.png
2017-12-19 21:12 Kyle_Katarn Assigned To => Kyle_Katarn
2017-12-19 21:12 Kyle_Katarn Status new => feedback
2017-12-19 21:12 Kyle_Katarn Note Added: 0002738
2017-12-20 13:53 TM123 File Added: Sumo2.png
2017-12-20 13:53 TM123 File Added: Sumo3.png
2017-12-20 13:53 TM123 Note Added: 0002741
2017-12-20 14:05 TM123 File Added: Sumo4.png
2017-12-20 14:05 TM123 Note Added: 0002742
2017-12-23 10:44 Kyle_Katarn Note Added: 0002746
2017-12-23 10:44 Kyle_Katarn Status feedback => acknowledged
2017-12-23 11:01 Kyle_Katarn Target Version => Long term
2018-03-08 08:30 TM123 File Added: Sumo_Differentversions.png
2018-03-08 08:30 TM123 Note Added: 0002801
2019-05-16 22:45 wolf Note Added: 0003312
2019-05-16 22:53 Kyle_Katarn Note Added: 0003313
2019-05-16 23:13 wolf Note Added: 0003316
2019-05-21 21:55 Kyle_Katarn Relationship added related to 0005493