View Issue Details

IDProjectCategoryView StatusLast Update
0001602SUMoNew Featurepublic2014-03-02 08:14
ReporterpoutnikgAssigned ToKyle_Katarn 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionreopened 
PlatformNotebook Lenovo T400OSWindows XPOS VersionProfesional SP3
Product Version3.1.4 
Target VersionFixed in Version3.3.0 
Summary0001602: SW Item version number masking to optionally ignore minor update levels
DescriptionIt may make sense to implement version number masking - analogical to internet subnet masks - to optionally ignore for some SW items minor updates.

It could be implemented in context menu as version number position, where changes will be ignored.

E.g. SUMO may lead users to all-must-be-updated disease.
Reasonable approach, especially for frequently updated software, is to focus only to functional updates, and ignore minor fixes, if no troubles are experienced.
TagsNo tags attached.

Relationships

related to 0001418 resolvedKyle_Katarn Ignore this update 
related to 0001486 resolvedKyle_Katarn "Skip this update for X days / for ever" function 
related to 0001663 closedKyle_Katarn skip update for x days 
related to 0001692 acknowledgedKyle_Katarn Version masking to address stable versus beta version lines/series. 
related to 0001783 acknowledgedKyle_Katarn Management of more product lines/series updates 

Activities

poutnikg

2012-06-13 19:33

reporter   ~0000868

something like

context menu ->
( optionally hierarchical ) Version masking ->
All versions
A.B.C.X mask
A.B.X.X mask
A.X.X.X mask

The change in last monitored position would be taken as minor, othewise major.

poutnikg

2012-06-13 19:39

reporter   ~0000869

Related complementary approach could be
to be able to ignore just current available version.

Lets say I have version 1.0.
Lets say there is available v1.1, that has irrelevant fixes or not interesting changes to me.
I would set SUMO to ignore this v1.1.
SUMO would mark at next checks my version 1.0 as uptodate,
until next version after 1.1 occurs.

poutnikg

2012-06-13 22:13

reporter   ~0000870

Hm, I revied recently the list of open issues
and I would bet it wos not there :-)

poutnikg

2012-07-19 21:24

reporter   ~0000962

Thanks for update.

But I am not sure the time criteria is optimal approach.
With short interval the same version will be reported again.
With long interval newer version will be missed.

Unless I missed some details in functionality....

bytehead

2012-07-19 23:33

reporter   ~0000965

I think both approaches are valid. When you're familiar with the development details and release cycles of the particular app then version masking might be preferable. But sometimes you're just not ready/not in the mood/not prepared to update something and just want to be reminded after a reasonable time. Both approaches make perfect sense to me and complement each other.

@poutnikg: Should we file a new bug or can we reopen this one?

Kyle_Katarn

2012-07-19 23:36

administrator   ~0000966

I prefer the time based approch with "logarithmic" scale (day / week / month / forever)

Would you mind if i close this issue again ?

poutnikg

2012-07-19 23:49

reporter   ~0000967

Relation of the issue to time is very indirect
and time solution does not solve it, just temporarily hides it.

But you are the developer, all I can do is just raise the voice. :-)
If you feel time silution is way to go, than close it.

bytehead

2012-07-19 23:53

reporter   ~0000968

Last edited: 2012-07-20 00:18

View 3 revisions

We still need a convenient way to edit all this exceptions via GUI afterwards (after you suppress something temporarily). Sure, it will be harder to find a combined solution, but if it could be done that would be a very nice thing to have indeed.

I'm all for universal approach, so please don't close it yet, at least until after you implement the exceptions "editor" and we can see what can be done with it.

poutnikg

2012-07-20 08:20

reporter   ~0000970

The approach of bytehead is reasonable, IMHO.

poutnikg

2012-08-04 09:22

reporter   ~0001010

Last edited: 2012-08-04 09:24

View 3 revisions

As a practical variant there is idea of version override feature,
like "pretend the version equals to current latest version".

It would have advantage
as the status change would be event triggered ( another updated released),
not time trigerred ( day/week/month/never).

As some incremental updates may be relevant to user and some not,
it could be very handy particularly with feature request

0001658: Custom addition of History/Changelog link
http://www.kcsoftwares.com/bugs/view.php?id=1658

Kyle_Katarn

2012-08-04 13:38

administrator   ~0001015

In fact i think that i've not been clear when i implemented the "skip this update->Forver". It does EXACTLY what bytehead suggested.

If you have v1.2.3.4 and v1.2.3.5 is released and selected as "skipped for ever" then as long as 1.2.3.5 is current, your v1.2.3.4 will "pretend" to be up to date.

But as soon as v1.2.3.6 is released, it will already pop up.

Isn't it precisely what you suggest ?

poutnikg

2012-08-04 14:30

reporter   ~0001019

Ah, I am sorry, I see I misuderstood the implementation.
I took is as itr forever pretends it is up-to-date.

So you can ignore my last comment.

Kyle_Katarn

2012-08-04 14:39

administrator   ~0001021

And then close the issue ?

bytehead

2012-08-04 14:44

reporter   ~0001023

Wait a bit, Kyle. I need to run now, but I might have some more useful comments on this. I'll get back here on Monday.

Kyle_Katarn

2012-08-04 14:49

administrator   ~0001025

ok !

poutnikg

2012-08-09 06:58

reporter   ~0001065

According to skipping updates....

..maybe better than visually pretending it is up-to date,
it could be keeping current local and available versions displayed,

but marking by Green mark and sorting it as green OK item.

Kyle_Katarn

2012-08-09 23:56

administrator   ~0001077

Good idea. Would you please post a new "issue" for that ?

Issue History

Date Modified Username Field Change
2012-06-13 17:06 poutnikg New Issue
2012-06-13 19:33 poutnikg Note Added: 0000868
2012-06-13 19:39 poutnikg Note Added: 0000869
2012-06-13 21:34 Kyle_Katarn Assigned To => Kyle_Katarn
2012-06-13 21:34 Kyle_Katarn Status new => acknowledged
2012-06-13 21:34 Kyle_Katarn Relationship added related to 0001418
2012-06-13 21:34 Kyle_Katarn Relationship added related to 0001486
2012-06-13 22:13 poutnikg Note Added: 0000870
2012-07-14 15:28 Kyle_Katarn Status acknowledged => resolved
2012-07-14 15:28 Kyle_Katarn Fixed in Version => 3.3.0
2012-07-14 15:28 Kyle_Katarn Resolution open => fixed
2012-07-19 21:24 poutnikg Note Added: 0000962
2012-07-19 21:24 poutnikg Status resolved => feedback
2012-07-19 21:24 poutnikg Resolution fixed => reopened
2012-07-19 23:33 bytehead Note Added: 0000965
2012-07-19 23:36 Kyle_Katarn Note Added: 0000966
2012-07-19 23:49 poutnikg Note Added: 0000967
2012-07-19 23:49 poutnikg Status feedback => assigned
2012-07-19 23:53 bytehead Note Added: 0000968
2012-07-19 23:54 bytehead Note Edited: 0000968 View Revisions
2012-07-20 00:18 bytehead Note Edited: 0000968 View Revisions
2012-07-20 08:20 poutnikg Note Added: 0000970
2012-08-04 09:22 poutnikg Note Added: 0001010
2012-08-04 09:23 poutnikg Note Edited: 0001010 View Revisions
2012-08-04 09:24 poutnikg Note Edited: 0001010 View Revisions
2012-08-04 13:38 Kyle_Katarn Note Added: 0001015
2012-08-04 13:38 Kyle_Katarn Status assigned => feedback
2012-08-04 14:30 poutnikg Note Added: 0001019
2012-08-04 14:30 poutnikg Status feedback => assigned
2012-08-04 14:39 Kyle_Katarn Note Added: 0001021
2012-08-04 14:44 bytehead Note Added: 0001023
2012-08-04 14:49 Kyle_Katarn Note Added: 0001025
2012-08-09 00:14 bytehead Relationship added related to 0001663
2012-08-09 06:58 poutnikg Note Added: 0001065
2012-08-09 23:56 Kyle_Katarn Note Added: 0001077
2012-08-13 18:32 bytehead Relationship added related to 0001692
2012-11-10 21:08 bytehead Relationship added related to 0001783
2013-09-17 20:07 Kyle_Katarn Status assigned => acknowledged