filerev and cache-control headers #19
Conversation
| @@ -1,18 +1,20 @@ | |||
| { | |||
| "name": "dominatr-grunt", | |||
| "version": "3.0.0", | |||
| "version": "3.1.0", | |||
There was a problem hiding this comment.
If someone goes from 3.0.0 to 3.1.0 and makes no changes to their codebase, versioning will break, yeah? Maybe keep the version bit in replace.js and mark it as deprecated, if you don't want to jump straight to v4 here.
There was a problem hiding this comment.
Guess it should be v4 then, all those ?v={{ VERSION }} strings should really be removed
There was a problem hiding this comment.
In general we should get better about making non-destructive changes and deprecating things, tho.
|
updated |
| @@ -24,12 +24,22 @@ require( "load-grunt-config" )( grunt, { | |||
|
|
|||
| ## Changelog | |||
|
|
|||
| #### 3.1.0 Cache and versioning changes | |||
There was a problem hiding this comment.
v4
Also, consider adding a "breaking changes" subheader to the majors in this list, I appreciate those on other changelogs.
|
betterer? |
|
Oh well I meant like in the angular changelog, they have a "breaking changes" subheader that list the specific breaking changes. Our "to upgrade" instructions kind of do that now, but only kinda, since we list how to upgrade for anything we changed, whether it was breaking or not. |
|
We generally release such small change sets that there is one change in each and it is either breaking or not. I feel like the additional clarification isn't needed unless the change set is large enough that someone might only run into an issue under certain situations. |
|
LGTM. Lemme throw it on partyslate-marketing real quick, I'll let you know if it works. |
|
Merging, nobody else use this until @Tathanen has signed off. |
filerev and cache-control headers
@vokal/web this one should be merged and released before dominatr. I don't have a project open to test the deployment on, if anyone has an opportunity to pull from my fork so they can test, that would be helpful.
Concept here is that we should be using far future cache-control headers for static assets, but to do so we have to version every static file. grunt-filerev creates a hash of the file, so as long as the contents don't change, it won't be necessary for the client to fetch a new file, which is on its own a improvement from our current cache busting strategy. filerev-replace does the work of regex replacing paths to those versioned files.