LibStub Versioning?

In the documentation there is this statement:

LibStub is a minimalistic versioning library embedded by thousands of other addons. It allows addons to more easily share libraries by checking for the most recent version and making it available to other installed addons.

I ask this because I’ve recently “LibStubbed” one of my libraries. So, should I choose to publish it, where or how do I register the library so that LibStub’s iterator can check it for updates? Would this be the ACE page on CurseForge?

Thanks,

It’s self checking using the major, minor version parameters passed to NewLibrary() each time an instance of that library is loaded.

You can read LibStub.lua to see how it works.

1 Like

I’ve examined the LibStub source pretty carefully, I think. Of course, I might have missed something, so let me try my question again. In the ACE documentation page for LibStub there is this statement:

An iterator over the registered major libraries.

The key word is registered.

Hence my questions.

Registered with whom?
How, or with whom, do devs register their libraries?

Thanks,

https://www.curseforge.com/wow/addons/libstub

If you look at say CallbackHandler-1.0 that comes with AstralKeys you’ll see

local MAJOR, MINOR = "CallbackHandler-1.0", 6
local CallbackHandler = LibStub:NewLibrary(MAJOR, MINOR)

Whereas the version that comes with EchoRaidTools is

local MAJOR, MINOR = "CallbackHandler-1.0", 7
local CallbackHandler = LibStub:NewLibrary(MAJOR, MINOR)

and the version that comes with the latest Ace3 alpha is

local MAJOR, MINOR = "CallbackHandler-1.0", 8
local CallbackHandler = LibStub:NewLibrary(MAJOR, MINOR)

[added]
If you download the latest version of Bazooka, it has a number of tests in Bazooka\libs\LibStub-1.0\tests\ that might interest you.
https://www.curseforge.com/wow/addons/bazooka/files/4549637

1 Like

Registered with LibSub when the library is loaded (either as a standalone addon or embedded with another addon).

The library name (major) and revision number (minor) are registered with LibStub via NewLibary(major, minor).

The first Library with a new name(major) is returned a table to impliment their methods etc. It’s why libraries (mostly?) will have the major number as part of the name.

If another library of the same name(major) and a revision number(minor), that is less than than or equal to a previous call to NewLibrary, tries to register with LibStub it is returned a nil and does nothing further (return).

Same major and a minor that is greater than a previous registration is return the previous major table for updating (overwriting).

An addon using a library asks LibStub for the name(major) and LibStub returns the corresponing major table (containing the highest registered minor “updates”) along with the highest registered minor number.

The documented “Using Revision Control system tags for minor version” looks like it’s intended for someone using Git (or other version control system) with automated packaging/publishing.

1 Like

OK, I think I understand. Revision control systems not withstanding, LibStub only knows about local libraries (i.e., running in single WoW client’s addon namespace). It’s still up to the user to use services like Curse Forge to ensure that their libraries, addons, etc., are up to date.

Correct. That is why on patch days you might see people posting about erros and the response being “download the latest version of (library x) and put it in the addon”.

But that’s the same version control that applies to all addons, hence the love of addon managers.

Automated packager(s) may also automatically get the latest libraries from Git etc. when run but not my area of expertise.

Yeah, that’s why I install the latest alpha of Ace3 separately in addition to whatever’s included with my addons.

1 Like

I’d like to know more about packaging. But that’s for another time. thanks, as always.

https://support.curseforge.com/en/support/solutions/articles/9000197952-preparing-the-packagemeta-file

https://support.curseforge.com/en/support/solutions/articles/9000197281-automatic-packaging