Grunt just released a new 0.4 version and there were many changes from its previous versions.The two plugins I maintain also needed to be migrated, and I just finished porting them to the newer version. This also enabled me to port my other projects that depend on this, to the latest version of Grunt.
Porting the plugins
Moving the plugins to the newer versions of Grunt was the easy task - the only API that affected them was changing grunt.utils to grunt.util. I was able to upgrade grunt-node-qunit and grunt-saucelabs. One of my projects depends on grunt-jsmin-sourcemap, and looks like there are more things to update (references to this.file, etc) and that may take a little longer.
Porting the projects
Updating the projects themselves was more work. With all default plugins now moving to grunt-contrib, I had to manually change package.json to reference individual grunt-contrib-* plugins. Including grunt-contrib is an option, but grunt-contrib on the whole is pretty large and takes a long time to install. Once in package.json, each plugin now has to be loaded using the grunt.loadNPMTasks.
Thoughts about Grunt 0.4
In general, I think Grunt 0.4 is a great step forward. The breaking changes in the API are bad, but in my opinion, necessary. Grunt is now being increasingly used in many major products and hence should move to a 1.0 soon.
Separating grunt into grunt, grunt-cli and grunt-init was the biggest change. Grunt-init will soon be replaced by Yeoman, and that is consistent with what most developers start for scaffolding projects. However, I am still trying to understand the logic behind separating grunt-cli and grunt. I do realize that grunt-cli has command completion too, but in almost all cases, users would install both of them together anyway. The grunt-cli is good for developer machines where grunt in run from the shell, but for CI, I would prefer running something like npm test instead of having to install grunt-cli and then running the tests.
Changing the name of the Gruntfile was a great idea - it tells us that the file is just a grunt runner file, and not the grunt plugin itself. Its even better for Windows users like me who do not have to explicitly invoke grunt.cmd or alias it to run grunt.
All plugins have been moved to grunt-contrib and that keeps grunt extensible. However, the annoyance resulting out of this is to include the plugin in package.json, and then loading them in the Gruntfile.js using grunt.loadNpmTask. I am sure someone will write a script to read package.json and simply load all plugins that are prefixed with grunt. Loading whole grunt-contrib just takes a lot of time and installs a lot of plugins.
Removing directives was another great idea - I have always found it to be confusing. Replacing it with the accepted template system makes things a lot easier to understand.
Overall, this is a Grunt 0.4 is a great upgrade and hope it gets to a stable 1.0 version soon.
