Installed Minion. Same bug as a year ago when I last tried it. If you are now selling Premium services, this is simply unprofessional to leave such a glaring bug in your software.

It seems your programmers have not included the logic required to assist Minion in counting.

20 addons are listed that show an "an update" for an addon that has a lower incremental version number on wowinterface than had been previously updated to a higher version by the Curse client. I do understand that this is because the addon author has not updated the addon on your site, but nevertheless, it is quite simple to determine that for example, Version 3.2.3 of Quartz that you say is an update, is a lower version than the 3.2.5 that I have installed.

Fix this and your tool may be considered usable.

Oh and for goodness font 6? Fix that too. It is unreadable on modern hi-res monitors.

it is quite simple to determine that for example, Version 3.2.3 of Quartz that you say is an update, is a lower version than the 3.2.5 that I have installed.

And which of these is newer? 2.9 or 2.10? How about 2.09 and 2.10? 2.9a and 2.9b? 2.9-beta and 2.9? 2.9 beta and 2.9 release? 2.9 kitten eater and 2.9 stable? 2.9-18.10.15 and 2.9-19.10.15? Albatross-5 and Albatross-6? Can you use the same rule for each of these scenarios? The logic is QUITE complex, and can't possibly account for every possible scenario as an author can label their versions however they like.

__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh

Oh and for goodness font 6? Fix that too. It is unreadable on modern hi-res monitors.

I've tried to be a bit more... politic... about this, but yes, it's quite ridiculous. Sadly, Blizzard themselves are not much better, with the Battle.net desktop app itself being almost as bad; the font there isn't any bigger, but at least it has better contrast with the background color so it's slightly more readable.

Originally Posted by Seerah

And which of these is newer? 2.9 or 2.10? How about 2.09 and 2.10? 2.9a and 2.9b? 2.9-beta and 2.9? 2.9 beta and 2.9 release? 2.9 kitten eater and 2.9 stable? 2.9-18.10.15 and 2.9-19.10.15? Albatross-5 and Albatross-6? Can you use the same rule for each of these scenarios? The logic is QUITE complex, and can't possibly account for every possible scenario as an author can label their versions however they like.

Yes, there are some complexities, but most of those examples you gave are painfully simple (the only one that wouldn't be covered by a small set of basic software verisioning patterns would be "2.9 kitten eater vs 2.9 stable"), as are most of the mistakes in version comparison I've seen "live" in Minion itself.

I know developer time isn't unlimited, but the nearly imperceptible pace of development has been pretty disappointing. I fire up Minion every 6 months or so to test and try to give feedback in the hopes it will be helpful, but there's no way I could use it as my regular addon updater in its current state, even discounting the visual accessibility issues.

Complex? Yes? Fixable easily. Instead of free form, try structuring the version info. Major.Minor.Type. For example, 1.01a or 1.01b or 1.01. Before you go on about how hard it is to sort the alpha characters, don't. I can use Minion, but it gets frustrating when an author updates both Curse and WoWI and I update with one client and the other says there is an update to be applied.

What I have read in posts like this is how difficult it is to do apply versioning control. What I haven't read is what can be done to fix this or an attempt by the site maintainers to do so. Sorry if I missed that they have done this, but this topic keeps coming up with similar response.

Please describe in 3 sentences the logic of version numbers so that a parser can "read" it as a compareable value.

You cant because there is no RFC for version numbers. Everyone can name them as they like.

1.60200
2.60200
3.60200
1.60400
2.60400

We as addon authors/users "see" that the last part is probably an indicator for the game version and the first value is simply a counter for versions per extension. We would load the last one to get the latest. A numeric compare would load the third. While this is just a bad example there are dozens of habits when it comes to version numbers that contradict each other. So its not easy for a parser to find really the latest.

TeX has an idiosyncratic version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches π; this is a form of unary numbering – the version number is the number of digits. The current version is 3.14159265. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer Donald Knuth has stated that the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.

__________________
The cataclysm broke the world ... and the pandas could not fix it!

Instead of quoting one small part of my post, you should look at the next sentence. "Instead of free form, try structuring the version info." Perhaps I should have been more specific.

I have not fully developed an addon for WoW, but I have done software development. Having structure in the work place is doable. Of course with an audience as big as WoWI, no. If you use free form. Can you not enforce numbering fields with another field for things like Alpha, Beta etc...? Perhaps not, maybe I am missing something.

My latter statement stands, that what I have read is why this cannot be done and not "We tried this and it didn't work etc...".

My 2 bits

Originally Posted by Rilgamon

Please describe in 3 sentences the logic of version numbers so that a parser can "read" it as a compareable value.

You cant because there is no RFC for version numbers. Everyone can name them as they like.

1.60200
2.60200
3.60200
1.60400
2.60400

We as addon authors/users "see" that the last part is probably an indicator for the game version and the first value is simply a counter for versions per extension. We would load the last one to get the latest. A numeric compare would load the third. While this is just a bad example there are dozens of habits when it comes to version numbers that contradict each other. So its not easy for a parser to find really the latest.

There is nothing you can do (that would fix it). The "problem" is not with wowi or curse. Addons are not created for wowi or curse. Everyone and his mother packs together an addon. Version numbering is not a part of the development for non-programmers.

I've written and deleted 3 times now this text Because in the end I cant change the situation and dont know the plan for minion other than what was written the last time we discussed this

__________________
The cataclysm broke the world ... and the pandas could not fix it!

There is nothing you can do (that would fix it). The "problem" is not with wowi or curse. Addons are not created for wowi or curse. Everyone and his mother packs together an addon. Version numbering is not a part of the development for non-programmers.

I've written and deleted 3 times now this text Because in the end I cant change the situation and dont know the plan for minion other than what was written the last time we discussed this

I still think it's a good idea and with a way to submit versioning schemes and test them out I believe we'd get 99% detection before long.
With better visibility maybe some of the outliers with odd versioning schemes would help or switch to an easier format.

And which of these is newer? 2.9 or 2.10? How about 2.09 and 2.10? 2.9a and 2.9b? 2.9-beta and 2.9? 2.9 beta and 2.9 release? 2.9 kitten eater and 2.9 stable? 2.9-18.10.15 and 2.9-19.10.15? Albatross-5 and Albatross-6? Can you use the same rule for each of these scenarios? The logic is QUITE complex, and can't possibly account for every possible scenario as an author can label their versions however they like.

Please describe in 3 sentences the logic of version numbers so that a parser can "read" it as a compareable value.
1.60200
2.60200
3.60200
1.60400
2.60400

Please show me an example of an addon using such a versioning scheme. I have never seen one. I have seen:

60200.1
60200.2
60200.3
60400.1
60400.2

...and that, along with pretty much every verison numbering scheme I've seen mis-detected in Minion, is easily parsed with a few simple rules -- strip "^r%s*", "^v%s*", and other common meaningless prefixes; split on . and - characters; and do simple sorts on the parts. You'd need an additional rule to cover "6.2 Beta" vs "6.2 Release/Stable" and you wouldn't be able to parse Git hashes in WowAce alpha packages, but for the most part, it's very doable. Yes, there will be a few "special" versioning schemes (I'm looking at you, OPie) that can't easily be handled this way, but again, for the most part, it's just not this hard.

Tonyleila's suggestion about comparing the dates is a good one in a perfect world, but may not always be reliable since you can't control how files on the user's machine are timestamped. Let's say an addon is on both Curse and WoWI. The version on Curse is version 5 and was released in December 2013. The version on WoWI is version 12 and was released in August 2015. Now let's say the user just found this addon on Curse and installed it today (October 2015). Now the files on their computer are (definitely if they installed with the Curse Client, and maybe if they installed manually, depending on their software and how it's configured) marked as created/modified October 2015, so checking that against the August 2015 date of the newer version on WoWI will fail.

The scenario for the file date is not as easy as it seems,too. Which file will you check in addons that have the options in lua files or settings in the toc file?

I woud say the toc file because the Author has to change it every time he reuploads a new version. If you try to upload a new version on curseforge without updating the toc you get blocked. But I think its even better to just compare the date of ALL files inside the addons folder - so its easy to check if the user has made changes on the addon files and show this addon as modified like in curse client.

I woud say the toc file because the Author has to change it every time he reuploads a new version. If you try to upload a new version on curseforge without updating the toc you get blocked. But I think its even better to just compare the date of ALL files inside the addons folder - so its easy to check if the user has made changes on the addon files and show this addon as modified like in curse client.

Not true. In most cases, a change to the ToC isn't required at all. The only reasons to do so would be to add/remove things to load, such as files or libraries, or to change the Interface version when there's a new patch. Requiring that for every AddOn update would be a great deal more than annoying, since it would force the author to invent new ways to make the ToC different... and when you have cases of three updates to the same AddOn in a given day, that could become rage-inducing.

There are no rules to begin with. Authors can use whatever versioning scheme they wish. And they're doing this for free, in their free time, many with no outside programming experience.

__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh