View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000542||SUMo||Bug||public||2008-04-04 08:09||2012-03-10 22:40|
|Reporter||Zer0 Voltage||Assigned To||Kyle_Katarn|
|Target Version||Fixed in Version||3.0|
|Summary||0000542: SUMo do not support version digits > 256|
|Description||System Information for Windows (SIW), available here:|
has changed its version number format with the most recent release.
The latest version is 2008.4.2.0 (based on the date) - but before this release, SIW used a more standard 1.xx.xxx version numbering system (with the previous release being 1.73.638).
This change seems to have confused the Get Update server.
While SUMo itself sees the new version number properly and says no update is available, the product's "Get Update" web page:
will not list the new version as the latest (still incorrectly saying 1.73.638 is the latest). In fact, it will not list this new version number at all.
I'm not aware of any other software which has changed its version numbering system like this, so technically I'm not really sure if this is a SIW-specific problem or if it would also happen to other programs if they did something similar.
|Tags||No tags attached.|
I'm almost sure that it comes from a "out of bound" version coding in my datamodel due to "2008" as primary major version number.
It's high time i make something more efficient ...
Ah, OK, I wasn't sure. I thought it was just too smart for its own good - believing a software version couldn't suddenly jump from 1.x to 2008.x overnight without 2,006 other major versions in between. :)
All things considered, it's amazing just how well SUMo does work. Technically you're completely at the mercy of vast numbers of outside developers around the world and have to hope they don't keep changing the rules on you like this. ;) You should be proud of the success rate SUMo has - far higher than Appget, filehippo.com's Update Checker, RadarSync, UpdateStar, and VersionTracker Pro. In fact, when you consider all of those find fewer programs and still have higher false rates and problems, you're doing an even more incredible job.
Too bad i'm coding version numbers on 1 byte which make any version number chunk higher than 256 out of bound ;-)
That may lead to even more problems when you add driver checking support...
In fact, that issue - in combination with the 2 decimal limitation issue I previously reported here:
may make driver version checking significantly unreliable. ALL drivers on my systems are using the standard 3 decimal "major.minor[.build[.revision]]" or "major.minor[.maintenance[.build]]" version scheme - and many either use the year or something else over 256 in the version number.
I think both of these issues may need to be addressed before anything else major. They represent rather serious limitations that can affect the program's credibility.
For example, right now I already can't trust SUMo with any program that has more than 2 decimals in the version number (and that's hundreds of programs in my list). Even if SUMo says they're OK, I know I can't be sure - and that really defeats the entire purpose of the program. And now I guess I know I can't trust it if any numbers are above 256 either. It's also rather ironic that SUMo itself is using three decimals in its version number, meaning it potentially can't see its own updates! Technically, v18.104.22.168 beta users wouldn't know the v22.214.171.124 code was available. Not good... :(
You're damn right but i discovered this issue too late.
The only way to definitively fix this issue is to change the SUMo datamodel and DB / Appli interface.
I've already a good list of optimization that breaks the datamodel that wait for implementation. I'll make all this stuff at the same time... This would be a good reason for a v2.0 stamp ;-)
||Yeah, anything so major should probably be a 2.0 target. That will basically be like completely restarting the project. :)|
||lol ! If only you were joking... but i'm afraid it's gonna be true !|
||High version numbers (2008,...) not supported|
||Will this even be true with post-2.x releases? I'm not sure if driver monitoring will work reliably with such a limitation if so.|
||You're right : Re-opened, will have to be supported by post 2.x versions|
|2008-04-04 08:09||Zer0 Voltage||New Issue|
|2008-04-04 20:06||Kyle_Katarn||Note Added: 0000274|
|2008-04-04 20:06||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2008-04-04 20:06||Kyle_Katarn||Status||new => acknowledged|
|2008-04-05 03:14||Zer0 Voltage||Note Added: 0000279|
|2008-04-05 08:50||Kyle_Katarn||Note Added: 0000287|
|2008-04-10 04:51||Zer0 Voltage||Note Added: 0000299|
|2008-04-10 04:56||Zer0 Voltage||Note Edited: 0000299|
|2008-04-10 04:59||Zer0 Voltage||Note Edited: 0000299|
|2008-04-11 19:48||Kyle_Katarn||Note Added: 0000303|
|2008-04-13 23:31||Zer0 Voltage||Note Added: 0000306|
|2008-04-16 20:38||Kyle_Katarn||Note Added: 0000307|
|2008-05-26 23:34||Kyle_Katarn||Status||acknowledged => closed|
|2008-05-26 23:34||Kyle_Katarn||Note Added: 0000329|
|2008-05-26 23:34||Kyle_Katarn||Resolution||open => not fixable|
|2008-05-28 06:50||Zer0 Voltage||Status||closed => feedback|
|2008-05-28 06:50||Zer0 Voltage||Resolution||not fixable => reopened|
|2008-05-28 06:50||Zer0 Voltage||Note Added: 0000335|
|2008-05-28 19:57||Kyle_Katarn||Note Added: 0000338|
|2008-11-23 09:45||Kyle_Katarn||Status||feedback => acknowledged|
|2008-11-23 09:45||Kyle_Katarn||Summary||The "Get Update" Server Doesn't Understand Sudden Significant Version Changes => SUMo do not support version digits > 256|
|2009-01-09 17:55||Kyle_Katarn||Relationship added||has duplicate 0000958|
|2009-05-08 14:54||Kyle_Katarn||Relationship added||parent of 0000708|
|2012-01-10 22:47||Kyle_Katarn||Relationship added||duplicate of 0001448|
|2012-03-10 22:40||Kyle_Katarn||Status||acknowledged => resolved|
|2012-03-10 22:40||Kyle_Katarn||Fixed in Version||=> 3.0|
|2012-03-10 22:40||Kyle_Katarn||Resolution||reopened => fixed|