MySQL Workbench update doesn't exist

[ffurger]

Latest thinks there is a newer version of MySQL Workbench, v. 8.0.36.
However, as far as I can tell there is only a version 8.0.36.CE, which seems to be the latest version.
Note that trying to check for updates in Workbench invariably produces an error message.

[chucklessmith]

Noticing this too. Looks like (one possible | the) culprit line is this comparison of installed vs. remote version numbers?

https://github.com/mangerlahn/Latest/blob/main/Latest/Model/Update.swift#L52

Seems as though 8.0.36.CE (CE = Community Edition, I'm gonna guess) is evaluating as less than 8.0.36.

I could see proposing to truncate trailing non-numerical values when they're at the very end, but I suspect that'll cause things to go wrong in other instances; I see a few examples on my machine of a version number ending with some meaningful alphabetical values.

Maybe check to see if one version ends in a numeral and the other doesn't, and if so, compare just the numerical values; else compare the entire values?

Tempted just to go ahead and test this to see whether this works based on my limited test cases. We'll see when time affords!

[chucklessmith]

I do have a build that works around this issue.

I'm not sure what else I've broken in the process -- I'm running the stable release version as well as my alteration, and so far the only discrepancy I've encountered is this MySQL Workbench issue (i.e., it's solved, but I'm still not sure at what cost).

I'll happily share the change if that's of interest, but I'm wary about proposing a pull request, because it's entirely possible I also broke a ton of edge cases...

[ffurger]

Thank you, but I’ll pass on this.

…

On 15 Jun 2024, at 00:38, Chuck Smith ***@***.***> wrote: I do have a build that works around this issue. I'm not sure what else I've broken in the process -- I'm running the stable release version as well as my alteration, and so far the only discrepancy I've encountered is this MySQL Workbench issue (i.e., it's solved, but I'm still not sure at what cost). I'll happily share the change if that's of interest, but I'm wary about proposing a pull request, because it's entirely possible I also broke a ton of edge cases... — Reply to this email directly, view it on GitHub <#378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHLAYN2YW4ZRTNOVYC2TTXTZHNWIDAVCNFSM6AAAAABIBG2UJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYHA2DMOBXGQ>. You are receiving this because you authored the thread.

[jifbrodeur]

Hi, in fact the issue seems to be related to the .CE suffix of the community edition, IMHO latest should drop the .CE suffix when doing the version comparison the SQL Workbench.
Thanks

[chucklessmith]

Agreed @jifbrodeur -- For this particular case, yeah, dropping the version-final alphabetical characters works for the new-version-exists logic, but there are several other edge cases each being separately accounted for, and the code suggests there may need to be a whole rethink on the version comparisons into something that works more universally. That would, of course, be best as opposed to writing update logic for every nonstandard or unusual version numbering system out there.

As I mentioned earlier, though, I do have a build that solves the MySQL Workbench issue specifically.

[jifbrodeur]

@chucklessmith Your point of view is very valid, writing a switch or if for every exception might not be a good way to implement a maintainable solution. Maybe having two version of the software the CE and the non CE version could be a better way to resolve the issue, that is If Oracle always append a .CE at the end of the Community Edition version of MySQL Workbench?