Authors CurseForge

Not exactly a packager problem, but I have an uploaded ZIP file on CurseForge for Ovale that was approved four hours ago, but the new release information has not propagated to Curse.com yet. Is there something else I need to do to get that working again?

curseforge-packager now supports both Git and SVN repositories.

So, it turns out that you can checkout a subdirectory of a Git repository using a feature called "sparse checkout" since Git 1.7. Maybe the pkgmeta specification could be extended to allow checking out a subdirectory? For example,

externals:
    url: git://git.wowace.com/wow/libfoo/mainline.git
    subdir: libfoobar

I'm going to try to make it work with Subversion repositories as well so the tool can be more widely used. I just feel like having a standalone packager you can run locally is superior to the auto magic that happens when you tag the repository. If we could upload "nolib" versions as well that were understood by the Curse Client, I think this would be close to feature-complete.

curseforge-packager now supports additional repository keyword replacements, including the @localization@ keyword.

I tested using it to package Grid and it looks like it's working properly.

What is the rule for when "--@debug@" is replaced in Lua files? Is it when the package is created from a non-release tag? What about if there is no tag, i.e., an alpha release?

Quote from Torhal

No. There are under-the-hood flags for -nolib files which the Client looks at when determining what to install.

Just to clarify, so if I do manual uploads of ZIP files, then there is no way to provide a "-nolib" ZIP file that can be used by Curse Client?

That's a good point, but I've been trying to be a good citizen with using Curse services since I do use their localization stuff, and I figure keeping the repo and the pages here up to date is good for helping their web traffic in return. I'm not sure how many people pull the repo for Ovale other than Sidoine and myself, but just-in-case, I've kept pushing my changes here as well as on GitHub.

Is there some race condition we should be aware of when we upload files? Like "Wait 15 minutes after pushing your tags to the Git repository before you upload a release file"?

As the subject asks: how does Curse.com determine which file upload is the "newest file"?

You can see here for Ovale that I recently uploaded 6.0.53 and it is available in the "other downloads" tab as a "release" file, but the main page still says that 6.0.52 (the previous release) is still the newest file available.

I have been doing direct file uploads instead of relying on the packager so as to avoid packaging problems, but now I'm running into a different set of problems :-/

I notice that the "nolib" release files aren't available for download through a project's Curse.com page. Instead, they must be installed either through Curse Client or downloaded directly from the project's CF/WA development page.

If I upload a file named "project-1.0-nolib.zip", will it automatically be ignored by whatever process that updates the Curse.com project page with the latest release?

The .pkgmeta format could always be extended so that an "externals" listing could have an "embed" key that defaulted to a boolean value of "no", but could be set to "yes" to include that external checkout in a -nolib package, e.g.,

externals:
    libs/LibStub:
        url: svn://svn.wowace.com/wow/libstub/mainline/trunk
        tag: latest
        embed: yes

Then you wouldn't need to hard-embed anything in your addon. The .pkgmeta instructs the packager to always include the external checkout in the package, -nolib or not.

Off-topic, but is there a timetable posted anywhere for when we might transition to the new platform?

Is there a way to disable the voting mechanism for tickets?

curseforge-packager now supports "move-folders".