If I have an addon that will work in both retail and classic, are there any plans for enhancing the .TOC so that the addon can have both “##Interface:” versions listed?
Are there any other recommendations or plans for how addon authors should support both versions of WoW?
You can use different versions for your addon which would also help to keep them in-sync if you are maintaining seperate ## Interface numbers for an “up-to-date” addons list. It would also depend on the version numbering mechanism you use.
If you use something like:
you could:
local version = GetAddOnMetadata("YourAddonName", "Version")
version = gsub(version, "%.", "")
version = tonumber(version)
which would result in 1131 and 826 respectively.
There’s also the WOW_PROJECT_ID which should be 1 for retail and 2 for Classic.
/run print(WOW_PROJECT_ID)
The version number of the addon isn’t the issue. The “##Interface: 11320” vs. “##Interface: 80200” is the issue. The current .toc doesn’t allow (or recognize) two ##Interface lines.
A solution to this might be to leave ##Interface: alone but add “##Retail: 80200” and “##Classic: 11320” so an addon can actually have one set of files (including one .toc file) that would not be “Out of Date” on either system.
Alternatively, the package managers could be enhanced to have two .toc files (.toc_retail and .toc_classic) and would build two .zip files instead of one.
At the moment, it appears that for an addon to support both retail and classic it needs two separate repositories. I’d welcome being educated how other addon authors are solving this problem.
The out-of-date indicator has never really meant that much and is probably not worth agonising over.
I have addons that are separate versions for BfA and Classic and one that supports both under the 80200 version id simply because BfA won’t load 11320 (pre-secure) addons. One addon is currently separate but will become one because, well, it’s not worth agonising over.
Not saying Blizzard won’t change the internals to better understand the difference but seeing as it makes no difference at the code level, I wouldn’t hold my breath.
This is almost exactly what has been done, see the BigWigs packager
https://github.com/BigWigsMods/packager
https://twitter.com/WeakAuras/status/1166495588856340480
Addons need to package separate zips for 80200 and 11302
Neither CurseForge or the WoW UI devs are willing to make this easier for us
#@retail@
## Interface: 80200
#@end-retail@
#@non-retail@
# ## Interface: 11302
#@end-non-retail@
With Blizzard mentioning that TBC servers “might” be a thing, #@retail@/#@non-retail@ might not be far enough 
For Wholly and Grail I just use Interface values appropriate for the loadable addons, but the main ones I have 80200 and hope the user loads out-of-date addons in Classic.
Where do I find this use of #@non-retail@ etc. documented?
All I could find it this:
https://github.com/ultijlam/curseforge-packager
So there is nothing official from curseforge itself to achieve this?
They don’t support it, no. You have to do manual uploads or use the bigwigs packager
All right thanks!
just use the TOC version number retail needs and dont worry about it.
everyone disables the out of date addons alert because if they didnt then nothing would ever work.
if youre using curse/twitch you can just upload the same file twice. from the files tab edit the first file you upload, clear the supported wow versions, then set the supported classic versions, and save. for the second upload just leave it as is, it will default to retail anyway.
dont tag it as supporting both retail and classic versions, that breaks twitch and it wont show.
Thanks for this further advice. Actually I am currently looking into using an automatic packager, such that I don’t even have to manually upload my files via the webpages of curse or wowi.
I found this to be a promising guide, but I have not had time yet to delve further into it.
https://www.wowinterface.com/forums/showthread.php?t=55801