With the recent 5.17 tag, we had a number of people complain of errors which seem to be caused by their addon managers updating WA to 5.17 during gameplay, causing WeakAurasOptions to be a newer revision than WeakAuras. We could probably detect this condition and advise the user to reload their UI, so that the changes would apply to the core addon as well.

Oh that's happening? I guess checking C_Addons.GetAddOnMetaData("WeakAurasOptions", "Version") vs versionString before loading the options might work.

Looking at it again it's actually not that hard to implement: We just have to add a .lua file to WeakAurasOptions.toc with roughly:

local optionsVersion = @project-version@
if optionsVersion == "@project-version@" then optionsVersion == "Dev" end
if optionsVersion ~= WeakAuras.versionFromToc then
  WeakAuras.prettyPrint("Don't update while the game is running")
  WeakAuras.IsLibsOk = function() return false end
  WeakAuras.ToggleOptions = function()
       WeakAuras.prettyPrint("Don't update while the game is running")
  end
end

I think that might work.

with if optionsVersion == "@project-version@" then packager would make it be true, right?

if optionsVersion:sub(2, 16) == "project-version" then

Oh that's true, so the packager doesn't do @ replacements in the .lua files?

in Init.lua it works because of

--@debug@
...
--@end-debug@

no, I'm confussed, that should be:

--@debug@
optionsVersion = "Dev"
--@end-debug@

No that won't work for git checkouts, because that would make optionsVersion = "Dev" and WeakAuras.versionFromToc is "@Project-Version@"

Eh I was too tired yesterday, doing the same as Init.lua will work for both git checkouts, and all builds.

So yeah it is not that hard to implement.

I did implement that in 0c66980, but I believe that it doesn't actually work. In my testing if I edit the .toc file with a different version after login, the game ignores that. If I do the edit before starting the game it the detection works and an error message is shown.

I've looked at that with the process monitor, and the game does read all .toc files at startup, even from disabled addons. There's an additional read on login of the .toc files. I think that information is then cached.

The actual .lua files are not read until they are actually needed. Thus I believe we can't detect the user updating the addon while in game based on the .toc file. We would have to write a version marker into the .lua files at build time.

That's not hard, but for me, I don't think I'd invest the time to implement that, so that's up to you, whether that's worth your time.

That's unfortunate, hmm. Maybe we should log this as a "bug" for blizzard to look at? It's not great that sometimes the addon metadata api lies to us.

Like, if GetAddOnMetadata had the behavior that it updated its return values when a LoD addon was loaded, we could equally detect the problem by checking from the LoD addon's side.

I'm pretty sure that blizzard doesn't care that much. Though feel free to discuss it with meo, he probably has an idea whether bringing that up is worth the effort. Just for completeness I checked on the loading addon site, and the .toc file editing is not observed.

I think that we gotten several affected people is because while typically people update before launching the game, at expansion launch so many addons broke that people were triggered into unplanned updates.

I did implement it, let's see if we ever see someone ask what the messages means :)