Move release build from jQuery UI's grunt to here

[jzaefferer]

Everything that only runs when releasing jQuery UI shouldn't be inside it's Gruntfile. To make that happen, move things, then update build/release/release.js to call a DB method instead of invoking grunt release_cdn.

Stay in jQueryUI Grunt

• default: "lint csslint htmllint qunit"
• sizer: "concat:ui min:dist/jquery-ui.min.js compare_size:all"
• sizer_all: "concat:ui min compare_size"
• build: "concat min cssmin copy:dist_units_images"

Move to DownloadBuilder

• release: "clean build copy:dist copy:dist_min copy:dist_min_images copy:dist_css_min md5:dist zip:dist"
• release_themes: "release generate_themes copy:themes md5:themes zip:themes"
• release_cdn: "release_themes copy:cdn copy:cdn_min copy:cdn_i18n copy:cdn_i18n_min copy:cdn_min_images copy:cdn_themes md5:cdn zip:cdn"

The md5 generation can be simplified. We only need the MANIFEST file for the CDN bundle. We don't need it for the other two.

The zip task already has an equivalent. We should be able to use the zipping method in DB.

The copy task does a lot of stuff and has options for renaming files or stripping folders from paths. We should try to simplify that.

[rxaviers]

The release process step-by-step lives on the Release Checklist. Most of the steps are automated by a helper script, which currently lives inside the jQueryUI repo (at build/release/release.js). This script depends on a couple of grunt tasks that also lives inside jQueryUI repo (which is what title of this issue is about). Although the script (and its dependent grunt tasks) live inside the jQueryUI repo, they run in a completely independent way. One is supposed to fetch and execute it in a separate new empty working directory.

In the release process, Download Builder only takes place when generating the theme bundle package. Currently, DB offers a "public" method, which the release script can call to get this job done.

Said all that, while it makes total sense to move the release script away from jQueryUI, moving it into Download Builder (even as an intermediate step) has very little benefit (from common code point of view).

Setting up a separate repo now for the release script is the cleanest approach. Some of the benefits are:

• The repo in its own is a proper working directory. No need to create an empty directory and fetch the release.js file from the web to use it;
• Better dependency control. We can use packages.json in its default form to handle project's dependencies. (we don't need to npm install stuff in the middle of the code;

I've created it on http://github.com/rxaviers/jquery-ui-release. It currently works (using the release grunt tasks of jQueryUI). But, I'm still porting it (cutting its umbilical cord) away from the jQueryUI.

[scottgonzalez]

I do not want a separate repo for a single file.

[rxaviers]

I've misunderstood the goal then. Nevermind. As discussed, we're not moving the whole release automation away from jQueryUI, but leaving it there while only cutting off the duplicate-with-DB parts.