Idea: We should do a branch prior to rel…
Idea: We should do a branch prior to release (we do this anyway) and then commit to that branch a minimization of all JS and CSS, so trunk always has pretty-formatted, and release branches always have minimized.
Or this might not be needed with Andrew’s new stuff.
Denis de Bernardy 8:08 pm on April 1, 2009 Permalink
Isn’t there a way to add an svn hook on tag?
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.create.html#svn.reposadmin.create.hooks
That way, branches would also be pretty formatted, and only actual released versions would be minified.
D.
DD32 10:04 pm on April 1, 2009 Permalink
Its a thought, But many run on trunk daily anyway.
I cant remember what the constant is to use non-compressed scripts, Maybe if WP_DEBUG is enabled, then non-compressed scripts could be used instantly?
Xavier 8:37 am on April 2, 2009 Permalink
Sounds like a must to me.
Also, why not go one step further? Keep trunk’s PHP code clean and commented, and minimize that too in the release branche.
Of course, that would mean those why want to explorer WP’s inner-working would have to grab the trunk, and that older full-version of WP wouldn’t be fully available.
So (typing while thinking here), would it be cool to cater to everyone : provide a fully-minimized archive (PHP, CSS, JS) for default users, and keep a “maximized” archive as-well, for further reference?
(unless, it’s all part of an elaborate April-fools scheme, in which case, well, my case still holds
)
Gmcosta 5:45 pm on April 2, 2009 Permalink
too much work I suppose.
Peter Westwood 6:20 pm on April 7, 2009 Permalink
Minimising too much in the branch/tag will just make patching / generating patches too much work.
I can see the benefit of js/css minification but not php.
Xavier 2:50 pm on April 10, 2009 Permalink
@Peter: obviously, and likewise for CSS and JS, at a lesser level. Hence my suggestion for two archives per tag: a fully-minimized as default (for those who won’t look into the code), and an untouched one (for devs and the curious at heart).
I’m not suggesting minimizing in the branche, since that’s the basis for any further minor version, but for the the tag, which is meant to be definitive – or so I understand.
I could be way off, obviously. And the profit could me meaningless, but hey, we’re here to discuss
Robert Accettura 12:59 pm on April 2, 2009 Permalink
IMHO this should be part of tagging. There’s a few advantages here:
1. Less overhead for last minute changes on branch.
2. Most people who want optimization and polish and can’t do it themselves run tags anyway.
3. minimized code is harder to debug. If your not using a tag, you should have easy debug abilities.
Why not just automate the creation of a tag with a make/ant/shell/configure/whatever script that creates minimized versions of js/css (use the format [name].min.[ext]) when a tag is made and changes a flag in wp-config.php to prefer the .min if it exists. This has a few nice things:
1. Tagging is as simple as running a script which will create the tag, minify, and commit.
2. No worries about forgetting to update minified and non-minified code like on a branch since tags are (or should be) final.
3. By using a flag in wp-config.php to prefer minified version of js/css you can just change the flag to use the non-minified versions… This is awesome for when you want to debug.
4. Theme/plugin authors can utilize the wp-config flag to ensure their theme/plugin offer a minified/non-minified verisons.
5. As a bonus, you could include the minifier in WP to make it even easier when editing css/js via wp-admin.
Just my $0.02
Nate Moore 9:18 am on April 12, 2009 Permalink
I agree
Simon Wheatley 1:53 pm on April 18, 2009 Permalink
How about having the JS in two states: uncompressed (which the default enqueuing stuff uses if a constant, maybe reuse WPDEBUG?, is specified in wp-config.php) and compressed which is used by default. Uncompressed is used for dev, and an SVN post-commit hook script could automagically compress/minify/pack/whatever’s-currently-best the committed uncompressed JS files. An SVN ignore property could be set to ignore all *.cmp.js files (or some other filenaming schema for compressed files) to ensure they don’t get committed accidentally.
Peter Westwood 5:58 pm on April 18, 2009 Permalink
I believe this is sort of what Andrews code in trunk already does.
Look at the stuff in script-loader.php in wp-includes.
Shane 12:45 am on April 19, 2009 Permalink
I am kinda liking this idea.
Andrew Ozz 1:54 am on April 20, 2009 Permalink
Peter is right, that’s almost exactly how it works in trunk now. The switch to turn on .dev.js loading is SCRIPT_DEBUG.
Andrew Ozz 1:51 am on April 20, 2009 Permalink
Currently both the minimized (.js) and the non-minimized (.dev.js) versions of all custom scripts are included. This was mainly so we can test if minimizing works well. If we decide to go with two builds per release: “production” and “development”, we can remove the non-minimized scripts form the first (will have to change script-loader there too). This will reduce the download size/number of files in the install package a little bit, not sure if it’s worth it…
Stripping all PHPDoc/PHP comments would reduce the download size a lot more.