0001602: SW Item version number masking to optionally ignore minor update levels

(0000868)
poutnikg (reporter)
2012-06-13 19:33

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.

(0000869)
poutnikg (reporter)
2012-06-13 19:39

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.

(0000870)
poutnikg (reporter)
2012-06-13 22:13

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

(0000962)
poutnikg (reporter)
2012-07-19 21:24

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....

(0000965)
bytehead (updater)
2012-07-19 23:33

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?

(0000966)
Kyle_Katarn (administrator)
2012-07-19 23:36

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

Would you mind if i close this issue again ?

(0000967)
poutnikg (reporter)
2012-07-19 23:49

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.

(0000968)
bytehead (updater)
2012-07-19 23:53
edited on: 2012-07-20 00:18

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.

(0000970)
poutnikg (reporter)
2012-07-20 08:20

The approach of bytehead is reasonable, IMHO.

(0001010)
poutnikg (reporter)
2012-08-04 09:22
edited on: 2012-08-04 09:24

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 [^]

(0001015)
Kyle_Katarn (administrator)
2012-08-04 13:38

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 ?

(0001019)
poutnikg (reporter)
2012-08-04 14:30

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.

(0001021)
Kyle_Katarn (administrator)
2012-08-04 14:39

And then close the issue ?

(0001023)
bytehead (updater)
2012-08-04 14:44

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.

(0001025)
Kyle_Katarn (administrator)
2012-08-04 14:49

ok !

(0001065)
poutnikg (reporter)
2012-08-09 06:58

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.

(0001077)
Kyle_Katarn (administrator)
2012-08-09 23:56

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

Notes
(0000868) poutnikg (reporter) 2012-06-13 19:33	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.

(0000869) poutnikg (reporter) 2012-06-13 19:39	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.

(0000870) poutnikg (reporter) 2012-06-13 22:13	Hm, I revied recently the list of open issues and I would bet it wos not there :-)

(0000962) poutnikg (reporter) 2012-07-19 21:24	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....

(0000965) bytehead (updater) 2012-07-19 23:33	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?

(0000966) Kyle_Katarn (administrator) 2012-07-19 23:36	I prefer the time based approch with "logarithmic" scale (day / week / month / forever) Would you mind if i close this issue again ?

(0000967) poutnikg (reporter) 2012-07-19 23:49	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.

(0000968) bytehead (updater) 2012-07-19 23:53 edited on: 2012-07-20 00:18	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.

(0000970) poutnikg (reporter) 2012-07-20 08:20	The approach of bytehead is reasonable, IMHO.

(0001010) poutnikg (reporter) 2012-08-04 09:22 edited on: 2012-08-04 09:24	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 [^]

(0001015) Kyle_Katarn (administrator) 2012-08-04 13:38	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 ?

(0001019) poutnikg (reporter) 2012-08-04 14:30	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.

(0001021) Kyle_Katarn (administrator) 2012-08-04 14:39	And then close the issue ?

(0001023) bytehead (updater) 2012-08-04 14:44	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.

(0001025) Kyle_Katarn (administrator) 2012-08-04 14:49	ok !

(0001065) poutnikg (reporter) 2012-08-09 06:58	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.

(0001077) Kyle_Katarn (administrator) 2012-08-09 23:56	Good idea. Would you please post a new "issue" for that ?