View Issue Details

IDProjectCategoryView StatusLast Update
0001783SUMoRefactoringpublic2019-05-16 19:44
ReporterpoutnikgAssigned ToKyle_Katarn 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
PlatformDesktopOSWindows Vista 64OS VersionHome Premium SP2
Product Version3.4.8 
Target VersionFixed in Version 
Summary0001783: Management of more product lines/series updates
DescriptionConcerning Avidemux,
it brings general question about managing 2 product version series of the same product.
In some cases it would make sense to treat them separately as different products.

AFAIK, currently a user of latest Avidemux 2.5.6-1 from 2.5 line
will not be notified about eventual 2.5 line update,
but about 2.6 line update.
TagsNo tags attached.

Relationships

related to 0001602 acknowledgedKyle_Katarn SW Item version number masking to optionally ignore minor update levels 
related to 0001800 acknowledgedKyle_Katarn Optional time postponing of diplaying new versions 

Activities

bytehead

2012-10-10 01:14

reporter   ~0001239

JRE 6/7 belongs in here, too.

poutnikg

2012-10-19 11:40

reporter   ~0001262

Also Adobe Reader, it support even 3 version lines - 9, 10 and 11.

One of possible ways is to manage flags
beta
stable/release (possibly multiple)
obsolete

SUMO client could have set to search for either latest stable,
either for stable for given version line.( Adobe Reader 9, 10, 11 )

bytehead

2012-10-20 14:18

reporter   ~0001269

Last edited: 2012-10-22 21:57

View 4 revisions

Maybe let's implement two distinct modes of operation (preferably setup individually for every item listed):

1) show *minor* updates only -- meaning if you have installed Adobe Reader 9.x, it will only offer you 9.* versions;
2) show *highest* version available -- showing version 11.* in the same case now.

Although, this would only work for apps that separate their branches using consistent <MajorVersion>.<MinorVersion>.* numbering scheme. So, there will be unhandled exceptions, but I guess this approach would cover most of the useful cases already and shouldn't be too hard to implement.

bytehead

2012-10-20 14:31

reporter   ~0001270

^ Another alternative would be to use just an extra column for showing major updates. That is, always use the current Update column for minor updates and new column (say, Upgrade) to notify about major updates available -- showing both at the same time by default.

Then add ability for user to customize the column layout (choose which columns and [optionally] in what order to show). Thus, he/she can decide whether to see all or just minor/major updates only, even without reverting to the general preferences window.

bytehead

2012-10-22 18:47

reporter   ~0001279

^ Anyone thinks this idea worth a separate BR?

poutnikg

2012-10-23 01:49

reporter   ~0001286

For me, minor versus highest version makes sense.

Or, for an item, user could provide custom mask string, that would be checked for match.

Like "9.x" for offering only major version 9 updates.
or "1.3.x" for offering minor version 1.3 updates.

I guess I have already offered it before:
http://www.kcsoftwares.com/bugs/view.php?id=1602

bytehead

2012-10-23 06:12

reporter   ~0001287

Last edited: 2012-10-23 07:45

View 8 revisions

@poutnikg: I think your original idea in 0001602 is not bad in general, but so far it has some fundamental drawbacks, imho:

1) it's not practical for most users since it would require a very tedious and error prone task of client-side fine tuning for many items; moreover, this can only take place after local DB gets populated/updated, not in advance + in some cases, e.g. if we reset our DB, we might need to do it all over again;
2) it also might be pretty hard for users to maintain it properly in the long run;
3) it would be rather hard to implement properly even on the client side, because: [a] we need to take special care to keep this exception list free of duplicate, old and [especially] contradictory rules; [b] we need to implement a non-trivial support in GUI for proper management; [c] we also might need to take care of backup/copy/restore of these settings;
4) last but not least, it's a major effort from developer since it would require a serious revamping of client/server protocol, too.

This is why I was thinking how to solve the same problem in a much more simple and elegant way for both sides (users and developer). Sure, my approach is not as flexible and universal, but it has some serious advantages:

1) it's much easier to implement;
2) it doesn't require any manual setup and maintenance from users or server admin;
3) it's a much simpler idea to grasp for most users;
4) it would cover most of practical situations with parallel branches support.

Some protocol changes would still be needed I guess, but hopefully not as big.

poutnikg

2012-10-23 08:12

reporter   ~0001289

I agree, I just mean the reduced variant
is very similar or identical to you Highest versus Minor approach,
where such settings can be used implicitly by client.

By "I guess I have already offered it before" I meant something related.

about "extra column for showing major updates"
it could be also done by way of filtering out minor updates,
or pretending they are green.

poutnikg

2012-10-23 11:21

reporter   ~0001290

> This is why I was thinking how to solve the same problem in a much more simple
> and elegant way for both sides (users and developer).

This is related to my note in other topic
that user should not mark "black crows", but "white crows".

What is black and what is white depends on application.
For some white is beta, for some like MPC-HC, FFDShow is is stable.

bytehead

2012-10-23 18:01

reporter   ~0001291

Last edited: 2012-10-24 02:36

View 8 revisions

I like your black & white crows problem analogy ;) But I think you're mixing up two completely different (although related) issues here: (a) beta vs. non-beta designation (b) support for parallel development branches.

Imho, in order to keep things simple for everyone, they should be kept separate and addressed as such. As I understand, this particular topic is about problem (b) exactly.

Having two separate columns for reporting Minor/Major updates is a very simple and rather flexible way for users to get most of useful information in one place without any explicit setup and hard thinking. If the user is not interested in one or another, he/she should able to just hide one of the columns, that's it.

Besides, this thing does not rule out your former idea about visually marking and/or sorting skipped items with no Major updates (this could be added as a global setting). Then, what IS considered a Major update by SUMo, could be additionally clarified by per item mask: default is <Major>.*.*, which can be individually changed to <Major>.<Major>.*. Thus, this will be the only exception (simple and quite rare) for any user to ever setup.

To sum it up, our ideas could be combined.

poutnikg

2012-10-24 07:45

reporter   ~0001292

> I like your black & white crows problem analogy ;) But I think you're mixing up > two completely different (although related) issues here: (a) beta vs. non-beta > designation (b) support for parallel development branches.

In fact not. While I agree they are different topics, I have mentioned it
rather as illustration of needed optimized, effective model of user intervention.

But I like to see you like crows. :)

I agree ideas can be combined.

bytehead

2012-10-24 17:33

reporter   ~0001293

Last edited: 2012-10-24 17:37

View 4 revisions

We seem to have come to a consensus about crows with poutnikg :) What's your word on the matter, Kyle?

poutnikg

2013-01-19 12:25

reporter   ~0001360

Last edited: 2013-01-19 12:33

View 2 revisions

With Java 7 being at least untrusted, the topic becomes rather hot...

I think SUMO should treat multiple series lines of SW like Java JRE, Adobe Reader, etc as independent software.

wolf

2019-04-15 23:39

reporter   ~0003219

I'm not sure if I understood your proposal and which assumptions you make nor your abbreviation "BR". I can't see a solution without major redesign of SUMO on algorithm on server and client site. I relate it to software publishers maintenance strategy. As far as I understood your proposals, your proposal addresses several maintenance strategies of many software publishers, including JRE. But how does it cover Adobe Acrobat Reader, LibreOffice and various Intel SW with three and more stable product lines in addition to betas and rolling attribute version correlation?

I don't understand the algorithm yet as only part of that strategy is published. It seems to me an one dimensional record and strategy with several ordered conditionals to provide one dimension of information. But instead a solution seems to me to need a multidimensional record (vector) and algorithm, hence major internal redesign. The resulting advantage is less false positives reported. The operating system can be the second dimension. But for LibreOffice and Intel SW, there are different parameters as additional dimension. For LibreOffice it may be an atribute of stability resp. conservativity while for Intel SW the hardware generation seems an appropriate dimension not addressed by your simplistic version information. So I suppose the number of dimension needed is a combination of dimensions used in the various SW publishers maintenance strategy. For the example of LibreOffice and Intel SW they both need three dimensions, but their third dimension is independant resulting in a four dimension records with usage of changing dimensions according to maintenance product strategy. When making such considerations, it is worth reflecting if the beta attribute makes sense to add resp. integrate into the dimension strategy resulting in a separate dimension and obsoleting the current beta handling.

Take a look at reporting of Intel Driver and Support Assistant, including lookup of further information. Only with lookup of that further information over various updates especially for older hardware generations you'll get an idea of their version information. They report version for the (roling) actual hardware generation. If you've an older supported hardware generation, you'll get the same update, sooner or later, but with a different major and minor version.

The published SUMO strategy is not to rely on these software publishers dependencies and publications respectively hiding but instead replace it by observation of SUMO user agents. This observation seems to me almost one-dimensional and need to be replaced by such a multi-dimensional strategy.

wolf

2019-04-15 23:52

reporter   ~0003220

I forgot to mention the software installation strategy called side-by-side installation introduced into MS Windows more than 15 years ago.

I've no idea if it is meaningful to integrate such a deployment and usage strategy of application into this multi-dimensional scanning, recording and evaluating or keep it separated. Currently this deployment strategy can me managed for scanning by use of "additional file system directory" configuration option resulting in burden on user side if this strategy is used for many applications. The use of policies of Windows might be an option to address it for non-portable version of SUMO.

Kyle_Katarn

2019-04-17 21:41

administrator   ~0003226

This makes sense but that's the reason why this is still not implemented : requires a major redesign to get this feature and this is not possible on the short term.
Thanks !

Issue History

Date Modified Username Field Change
2012-10-05 07:53 poutnikg New Issue
2012-10-05 22:38 Kyle_Katarn Assigned To => Kyle_Katarn
2012-10-05 22:38 Kyle_Katarn Status new => acknowledged
2012-10-10 01:14 bytehead Note Added: 0001239
2012-10-19 11:40 poutnikg Note Added: 0001262
2012-10-20 14:18 bytehead Note Added: 0001269
2012-10-20 14:31 bytehead Note Added: 0001270
2012-10-20 19:30 bytehead Note Edited: 0001269 View Revisions
2012-10-22 18:47 bytehead Note Added: 0001279
2012-10-22 21:56 bytehead Note Edited: 0001269 View Revisions
2012-10-22 21:57 bytehead Note Edited: 0001269 View Revisions
2012-10-23 01:49 poutnikg Note Added: 0001286
2012-10-23 06:12 bytehead Note Added: 0001287
2012-10-23 06:15 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:39 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:41 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:41 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:43 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:44 bytehead Note Edited: 0001287 View Revisions
2012-10-23 07:45 bytehead Note Edited: 0001287 View Revisions
2012-10-23 08:12 poutnikg Note Added: 0001289
2012-10-23 11:21 poutnikg Note Added: 0001290
2012-10-23 18:01 bytehead Note Added: 0001291
2012-10-23 18:03 bytehead Note Edited: 0001291 View Revisions
2012-10-23 18:04 bytehead Note Edited: 0001291 View Revisions
2012-10-23 18:06 bytehead Note Edited: 0001291 View Revisions
2012-10-24 02:23 bytehead Note Edited: 0001291 View Revisions
2012-10-24 02:29 bytehead Note Edited: 0001291 View Revisions
2012-10-24 02:35 bytehead Note Edited: 0001291 View Revisions
2012-10-24 02:36 bytehead Note Edited: 0001291 View Revisions
2012-10-24 07:45 poutnikg Note Added: 0001292
2012-10-24 17:33 bytehead Note Added: 0001293
2012-10-24 17:36 bytehead Note Edited: 0001293 View Revisions
2012-10-24 17:37 bytehead Note Edited: 0001293 View Revisions
2012-10-24 17:37 bytehead Note Edited: 0001293 View Revisions
2012-11-10 21:06 bytehead Relationship added related to 0001800
2012-11-10 21:08 bytehead Relationship added related to 0001602
2013-01-19 12:25 poutnikg Note Added: 0001360
2013-01-19 12:33 poutnikg Note Edited: 0001360 View Revisions
2019-04-15 23:39 wolf Note Added: 0003219
2019-04-15 23:52 wolf Note Added: 0003220
2019-04-17 21:41 Kyle_Katarn Note Added: 0003226