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?
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,
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.
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?
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.,
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.
0
0
0
externals: url: git://git.wowace.com/wow/libfoo/mainline.git subdir: libfoobar0
0
I tested using it to package Grid and it looks like it's working properly.
0
0
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?
0
0
0
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 :-/
0
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?
0
externals: libs/LibStub: url: svn://svn.wowace.com/wow/libstub/mainline/trunk tag: latest embed: yesThen 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.
0
0
0