It sure whould be nice if libs had a consistant layout.
For example BabbleLib has both 2.0 and 2.1 version in it but 2.1 is burried a level down. Other libs have the "older" version burried but their .toc files don't inlcude the older versions so they don't get loaded.
I would like to sugest each "major" revision be places in a seperate dir in the SVN. For example for BabbleLib we would have the following
And the .toc for each would be set to LOD and load all the code in thier respective dirs.
This would make finding libs when developing an addon much easier it would also be easier when testing stuff etc. Since each toc is LOD they won't get loaded unless some addon needs them. It allso alows the !!!standalone sturcture towork and AceWinUpdater to work with the libs.
Discussed with Kael, I think this is the route we're gonna go:
Existing libs stay as they are, TOCs are edited to load all major versions contained unless an old version is depreciated, like compost. There must be good reason for not loading an old major version, "it's not supported anymore" doesn't count... must be a somewhat fatal reason.
New library major versions will go into their own addon like the FuBarPlugin libs are. So if a new TabletLib is created, the addon would be named Tablet-3.0.
Library packages like Ace2, PeriodicTable, SpecialEventsEmbed and such will remain as single packages, and it's up to the author if he wants to reversion the whole library into a separate addon or just load all major versions. Either way it must be possible without TOC edits for the end users to install the libraries they need and get all major versions loaded.
So taking this approch BabbleLib toc should be changed to load both 2.0 and 2.1 since it's an existing lib.
A couple of side notes/questions
Why is compost 1.0 so "bad"? I know if a couple of addons that use it.
One advantage of the seperate addon aproche is with LOD when you have no more addons that use lib-1.0 for example and all are using lib-2.0 lib-1.0 won't be loaded at all. The combined approch of "lib" that loades both versions cause 1.0 to load even if addons are only useing version 2.0.
I understand the advantage of seperating off the old ones, but it'll break a lot of externals and OptDeps... which is a PITA to fix. If the user is that concerned with the resources they can manually remove the old version.
Why is compost-1 "bad"? Because a number of mods were not niling out their local after a Reclaim and then later modifying a table... which would fuck over another mod that had the table. I added some doublechecks into the library te help weed out these issues, and as a result everyone should be using 2.0. There's no need to have two compost heaps saving tables, and the API is unchanged, so it's just a matter of pushing everyone over to 2.0. But in the end it doesn't matter much, because compost will be unneeded in TBC.
Okey, another point brought up in IRC by mjc... optdeps are becoming a bitch to manage. I'd like to add some logic into AceLibrary to load up libraries if a standalone can be found.
This is gonna need a twofold approach, thanks to the same issue above.
1) If "Something-2.0" is requested and an addon named "Something-2.0" exists, then load it up and pass it to the requesting mod.
2) If an addon named "Something-2.0" doesn't exist, scan all addons for a specific TOC metadata and load that mod. This metadata needs to account for addons containing many libs, like Babble and SpecialEvents. Probably something simple like "X-Ace2Lib-Something-2.0". Packages would have a TOC metadata line for each library it will load. Normal addons should not use these fields, only standalone library addons.
Ok so what you are wanting to do is remove the requirement for the addon to list the libs it's using as optiondeps and instead create a way for AceLibrary to "try" to figure it out for the addon by adding code to AceLibrary and meta date to the libs?
Why is it so difficult to add options deps to addons?
Oh and another radical idea I had.
Move all libs in the svn to a libs sub dir. Each major version of a lib in it's own sub dir under the libs dir. To be honest the addon list is getting so long it's getter hard to tell what is what and move the libs off to thier own dir aleast gets them out of the way. A link could be added to the svn that points down to the libs dir for each lib so old externals links end up getting the lib from the libs dir instead of the root of trunk thus avoiding a mass update of all externals links.
Now (assuming the above) if WinAceUpdater was updated to examine the externals when doing a w/o externals and instead of embeding the libs like w/ externals does but instead gets the lib from the /lib dir and geting it as a standalone lib.
Now the user when running WinAuceUpdater doesn't need bother with libs at all and can get addins using a method of libs of thier own choose. Either embeded (with externals) or standalone libs (w/o externals).
Moving existng shit on the SVN breaks lots of stuff. OptDep are a bit a hastle and not entirely needed now that the libs are all LoD. AceLibrary can very easily load up the libs when they are asked for if they aren't loaded. Making a single change to AL is a lot simpler than maintaining a bunch of optdeps.
Come back to me when ya got 50 mods in the SVN and tell me if it's hard to maintain :)
As for the whole issue of the directory structure, again moving things is a bad idea. If you want more info about mods get more devs making wiki pages. The zips aren't really there to be a nice easy addon directory like WoWI, they're there for people to get betas without the hastle of the SVN.
I LOVE how in the addons listing all the Libraries are grouped together, instead of spread out like they were some time back. THANK YOU ALL FOR DOING THIS!! It makes loading without externals that much better!!
I have a suggestion that I wanted to make (be afraid, be VERY afraid) after mistakingly putting the "-Ace2-" color tag ("|cff7fff7f") in the wrong spot of the title line in the TOC file. This mistake actually has some additional value if all library authors desired to adopt it. Placing that same color code (since they are in fact Ace2 libraries) at the START of every library will shove all libraries to the bottom of the addon listing ont he character selection screen - just like it did to my addon (which freaked me out cause it wasn't listed alphabetically like it should have been).
Since they are all LOD, leaving them checked on every character has no effect... but this addition places them outside of the normal addon listing for ease of navigation through the addons you DO want to have different per toon.
Example: "## Title: |cff7fff7fLib: Abacus-2.0|r" becomes "Lib: Abacus-2.0" in the addon list. Nothing but a cosmetic change.
Wha-chall' think? Not a top priority I know, but would it help at all? Perhaps some people... like the anal-retentive crowd out there <points at self>.
<edit> I saw that this was mentioned briefly, but not hit on directly in the other thread "New library standards", but I wanted to touch on it again. This would not effect any functionality of the addon, rather just it's location in the list when at the character screen. Bah, there I go repeating myself again...