Bust browser cache when building alpha/beta versions and when running from /src

[azaozz]

Bumpbot used to do this when minifying scripts and stylesheets. We can move cache busting to Grunt when building alpha/beta versions, and to script-loader.php when running from /src.

[azaozz]

In 26751.patch:

• Append the epoch time to $wp_version when building alpha|beta|RC versions.
• Append time() to $wp_version when running from /src.

Refreshing cache on every page load in /src may be a bit too aggressive but will help when debugging and testing js and css changes.

[nacin]

Taking a look at this.

[azaozz]

In 26751.1.patch:

• Drop the changes to script-loader for always refreshing in /src for now. All developers would know to refresh the browser caches :)
• Change the string appended to $wp_version on build to be the current date (yyyymmdd), so it refreshes once a day.

[nacin]

Two thoughts:

• A simple check for a hyphen should be sufficient once -src is removed.

• On the other hand, it'd be nice to ship a clean version number for beta and RC packages. To me this sounds like the date should only replace an existing date, thus requiring a developer to "restart" the count after a package. (And, thus, two hyphens can be looked for, then everything after the second hyphen removed and the date added.)

Agree/disagree/better idea?

[azaozz]

...it'd be nice to ship a clean version number for beta and RC packages.

True but then the nightlies won't bust the cache during beta and RC. One way to fix this is to have a separate var in version.php specifically for cache busting.

[nacin]

I only mean I'd like wordpress-3.9-beta1.zip to ship with the 3.9-beta1 version number. The next day's nightly can contain 3.9-beta1-$date. I'm not sure how to handle that. Thinking.

[azaozz]

Replying to nacin:

The best way seems to be to "manually" control it (like your suggestion above): only replacing an existing date string. It will need one more commit after releasing beta or RC (to add back the date string), but will be very straightforward.

[nacin]

We can do grunt.template.today for dates. I like this but let's do it in 4.0 at this point.

[azaozz]

Refreshed the patch to use grunt.template.today().

[nacin]

"If the version includes a date string, update it" gave me an idea. Rather than putting a date string in /src, we should continue to just put SVN revision strings, and replace those with a date. So, we'd bump to 4.0-beta1-src, then package and release 4.0-beta1, then bump to 4.0-beta1-29000-src, which will be packaged in the nightly as 4.0-beta1-20140702. I think this will work nicely, yes.

This has the added benefit of using the same format as auto updates already do on the API side, which will reduce the updates from every 12 hours to once a day.

Also: the nightly won't change if there weren't any commits that day as the grunt task wouldn't have been run on post-commit. (But also, the nightly script only runs when it detects there has been a commit.)

[nacin]

In 28611:

Append the date to $wp_version in the build output, for nightly packages.

props azaozz.
fixes #26751.

[netweb]

r28611 fails Grunt jshint:grunt task ​https://travis-ci.org/ntwb/wordpress/jobs/26274829

Running "jshint:grunt" (jshint) task
Linting Gruntfile.js ...ERROR
[L88:C53] W109: Strings must use singlequote.
              return "$wp_version = '" + version + "';"; 
[L88:C70] W109: Strings must use singlequote.
              return "$wp_version = '" + version + "';"; 
Warning: Task "jshint:grunt" failed. Use --force to continue.

Incoming 26751.4.diff fixes this

[azaozz]

Uh, my bad, didn't lint the patch :)

For readability's sake double quotes there make more sense, perhaps 26751.5.patch?

[netweb]

Replying to azaozz:

For readability's sake double quotes there make more sense, perhaps 26751.5.patch?

Agreed, readability matters (I had to reread my own patch ~10 times, didn't know we could override jshint like this)

[azaozz]

In 28620:

Fix double quote jshint warning in Gruntfile.js, fixes #26751

[azaozz]

Replying to nacin:

Rather than putting a date string in /src, we should continue to just put SVN revision strings, and replace those with a date.

Yeah, that is the best solution :)

The only thing remaining to maybe (eventually one day) consider is resurrecting part of bumpbot to automatically replace the SVN revision after changes to JS or CSS files are committed.