Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
I'm just posting this here in case there's interest. I was having a lot of trouble with the WowAce packager that was hooked into the Ovale Git repository, so I decided to write my own packager for Ovale. When I've pushed all my changes, I just run this script and it reads my .pkgmeta and .toc files and generates an appropriate ZIP file and embeds a CHANGELOG.txt file with the commits since the previous release. All you need is a Windows Git installation, and you should have all the base tools used by this script. If you have SVN externals, you'll also need a Windows SVN client installed to fetch them. If you have 7-Zip installed, it will create the ZIP file. It's assumed that all of these things can be executed from the command line.
# release.sh generates a zippable addon directory from a Git checkout.
#
# release.sh works by creating a new project directory, checking out external
# repositories within the project directory, then copying files from the Git
# checkout into the project directory. The project directory is then zipped to
# create a distributable addon zipfile.
#
# release.sh reads .pkgmeta and supports the following directives:
# - externals
# - ignore
# - manual-changelog
# - package-as
#
# release.sh supports the following repository substitution keywords when
# copying the files from the Git checkout into the project directory.
# - @project-version@
#
# release.sh reads the TOC file, if present, to determine the name of the
# project.
#
# release.sh assumes that annotated tags are named for the version numbers for
# the project. It will identify if the HEAD is tagged and use that as the
# current version number. It will search back through parent commits for the
# previous annotated tag that is a release version number and generate a
# changelog containing the commits since that previous release tag.
#
# By default, release.sh creates releases in a "release" subdirectory of the
# top-level directory of the Git checkout.
Looks very promising. I'll be sure to give it a try the next time the packager is ignoring me. My only comments for now are that:
1. Support for the "move-folders" directive would be nice, and shouldn't be too hard to implement.
2. It should probably also allow a "-beta" suffix:
Yes, "move-folders" should be easy based on the description, but I don't use it so I've not touched it.
Regarding "-beta", the way that release.sh currently works, all the stuff with tags is used mostly for assigning the version number and making the changelog. The assumption is that you want all changes since the previous release tag to the HEAD. If you don't tag the head, then it generates a Git-based version number that's basically the number of commits since the previous release tag. If you tag the head, then it uses the tag as the version number. Examples:
HEAD is tagged "1.2.3" and previous tag is "1.2.2". Then the version number is 1.2.3 and changes are from 1.2.2 to 1.2.3.
HEAD is tagged "1.2.3-beta" and the previous tag is "1.2.2". Then the version number is 1.2.3-beta and the changes are from 1.2.2 to 1.2.3-beta.
HEAD is tagged "1.2.3-beta2" and the previous tags are 1.2.3-beta and 1.2.2. Then the version number is 1.2.3-beta2 and the changes are from 1.2.2 to 1.2.3-beta2.
HEAD is untagged and 7 commits ahead of the previous tag 1.2.2. Then the version number is 1.2.2-7-g7e4ab1 (or whatever the hash for the HEAD is) and the changes are from 1.2.2 to HEAD.
One last use case for this script: I hack on my addons outside of my live addon directory, but I do this to publish my changes directly into the live addon directory:
sh release.sh -eoz -r "/c/Programs/World of Warcraft/Interface/AddOns"
This skips fetching externals and creating the zip file, but otherwise stages all of the files in your checkout and creates the changelog into the live addon directory. The funny path to the AddOns directory is just how the bash shell included with the Windows Git distribution wants paths -- UNIX-style instead of DOS-style.
This staging allows me to be fairly certain I'm running the exact same code as if I had installed the addon from Curse Client, so I know what users are going to be seeing.
1. Support for the "move-folders" directive would be nice, and shouldn't be too hard to implement.
I was reading the wiki and trying to determine exactly how "move-folders" works. Does it actually move the directory from the specified path to the top-level with the specified name? Or does it just copy the directory?
Still need to get around to trying this out... it should be especially good with the new API for uploading files to WoWInterface, since I wouldn't have to wait for the actual Curse packager to run, which is the leading cause of my addons not being synchonized on both sites. :p
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.
I think it could be used with CI tools like travis-ci.org to automagically create the archive from github.com. With some more scripting, it could be uploaded to github using their API; I suppose this could also be done with wowace and wowinterface.
wowace doesn't allow zip file uploads, which is a policy I personally like, as it ensures that everyone uses the repositories properly.
It's a policy that's been nothing but a pain in my ass due to the packager being so unreliable, and is the reason that I moved all of my addons (other than Grid) off the wowace.com domain and then out of Curse-hosted repositories altogether. The only reason I'm using Curse-hosted repos again now is because I'm using Git and can push to Curse in addition to another, actually reliable remote repo (GitHub). Grid is still in a WowAce SVN repo, and the server is down an unacceptably high percent (at least 10%) of the time when I try to commit changes.
It's still annoying to have to babysit the packager every time I tag a release to make sure it actually makes a ZIP file, but at least if it's not working, I have the option of just uploading a ZIP manually; without that option I'm very likely to simply forget about it if it still hasn't packaged by the time I go to bed, and then 6 months later I finally realize why people are still reporting a bug I fixed months and months ago. :rolleyes:
But yes, that's always been my impression, too, that Curse is just severely understaffed (even when features do get released, they're buggy from day one, and just never get fixed), so any tools we can use that don't depend on Curse getting shit done are very welcome.
You can find it over on GitHub:
1. Support for the "move-folders" directive would be nice, and shouldn't be too hard to implement.
2. It should probably also allow a "-beta" suffix:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, "move-folders" should be easy based on the description, but I don't use it so I've not touched it.
Regarding "-beta", the way that release.sh currently works, all the stuff with tags is used mostly for assigning the version number and making the changelog. The assumption is that you want all changes since the previous release tag to the HEAD. If you don't tag the head, then it generates a Git-based version number that's basically the number of commits since the previous release tag. If you tag the head, then it uses the tag as the version number. Examples:
This skips fetching externals and creating the zip file, but otherwise stages all of the files in your checkout and creates the changelog into the live addon directory. The funny path to the AddOns directory is just how the bash shell included with the Windows Git distribution wants paths -- UNIX-style instead of DOS-style.
This staging allows me to be fairly certain I'm running the exact same code as if I had installed the addon from Curse Client, so I know what users are going to be seeing.
I was reading the wiki and trying to determine exactly how "move-folders" works. Does it actually move the directory from the specified path to the top-level with the specified name? Or does it just copy the directory?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAnd your .pkgmeta contains this:
... then your resulting ZIP will contain this structure:
- MyAddon/ - Modules/ - (various files in here) - MyAddon.lua - MyAddon.toc - [B][COLOR="darkorchid"]MyAddon_Config[/COLOR][/B]/ - Config.lua - MyAddon_Config.tocBasically, after the final structure is created, any folders specified are moved (not copied) up to the top level.
I tested using it to package Grid and it looks like it's working properly.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIt's a policy that's been nothing but a pain in my ass due to the packager being so unreliable, and is the reason that I moved all of my addons (other than Grid) off the wowace.com domain and then out of Curse-hosted repositories altogether. The only reason I'm using Curse-hosted repos again now is because I'm using Git and can push to Curse in addition to another, actually reliable remote repo (GitHub). Grid is still in a WowAce SVN repo, and the server is down an unacceptably high percent (at least 10%) of the time when I try to commit changes.
It's still annoying to have to babysit the packager every time I tag a release to make sure it actually makes a ZIP file, but at least if it's not working, I have the option of just uploading a ZIP manually; without that option I'm very likely to simply forget about it if it still hasn't packaged by the time I go to bed, and then 6 months later I finally realize why people are still reporting a bug I fixed months and months ago. :rolleyes:
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorFixed that for you. :p
But yes, that's always been my impression, too, that Curse is just severely understaffed (even when features do get released, they're buggy from day one, and just never get fixed), so any tools we can use that don't depend on Curse getting shit done are very welcome.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorBut using CF is a valid choice to escape this WoWAce policy if you don't like it.