View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001602||SUMo||New Feature||public||2012-06-13 17:06||2014-03-02 08:14|
|Platform||Notebook Lenovo T400||OS||Windows XP||OS Version||Profesional SP3|
|Fixed in Version||3.3.0|
|Summary||0001602: SW Item version number masking to optionally ignore minor update levels|
|Description||It 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.
|Tags||No tags attached.|
|related to||0001418||resolved||Kyle_Katarn||Ignore this update|
|related to||0001486||resolved||Kyle_Katarn||"Skip this update for X days / for ever" function|
|related to||0001663||closed||Kyle_Katarn||skip update for x days|
|related to||0001692||acknowledged||Kyle_Katarn||Version masking to address stable versus beta version lines/series.|
|related to||0001783||acknowledged||Kyle_Katarn||Management of more product lines/series updates|
context menu ->
( optionally hierarchical ) Version masking ->
The change in last monitored position would be taken as minor, othewise major.
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.
Hm, I revied recently the list of open issues
and I would bet it wos not there :-)
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....
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?
I prefer the time based approch with "logarithmic" scale (day / week / month / forever)
Would you mind if i close this issue again ?
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.
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.
||The approach of bytehead is reasonable, IMHO.|
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
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 v220.127.116.11 and v18.104.22.168 is released and selected as "skipped for ever" then as long as 22.214.171.124 is current, your v126.96.36.199 will "pretend" to be up to date.
But as soon as v188.8.131.52 is released, it will already pop up.
Isn't it precisely what you suggest ?
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.
||And then close the issue ?|
||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.|
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.
||Good idea. Would you please post a new "issue" for that ?|
|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|