[thelist] Managing css, images, js versioning

Ken Snyder kendsnyder at gmail.com
Tue Dec 4 22:24:12 CST 2007


On 12/4/07, Bill Moseley <moseley at hank.org> wrote:
> ... I realize this varies a lot between systems and applications, but it's
> something I've been thinking about lately and it would be very helpful
> to hear how you handle this. ...

Two methods I've used before and found useful:

- Compile and minify js/css on demand.  On each page load, the server
checks file version strings, timestamps or file md5's to see if that
combination has ever been compiled into a file.  It is great for
developers because they don't have to manually trigger the compilation
and minification.  It is great for production because updating files
creates a new filename and automatically triggers the server cache to
update.  You could even use some type of config file or database query
to compute the hash based on revision numbers and svn export any
needed files.  In my case, we simply read the filename and
modification time of each file and created a two-part filename that
sat in a public cache folder: an md5 hash of the concatenated list of
files and a base36 string representing the sum of the timestamps.

- Use apache rewrite to properly map versions to files.  Keep a config
file or database with version numbers for each file.  In links, link
to a filename with the version in it (e.g. myjavascript.1000.js).  Set
up apache to map the file to the original name (e.g. myjavascript.js).
 Clients are refreshed each time a version number is changed.  We
actually did this with PHP on IIS even.


These ideas might not work well with js or css that include other
files.  They would need to be served up by a dynamic language to
update the filenames of included files.  Personally, I think that the
developers should resolve dependencies server side and avoid js/css
files that include other files.

You could also implement automation for updating of file/db configs
using subversion hooks.

As far as shared files, we did a separate media repository.  With
apps, you likely have one repository for each app.  If you share
resources such as css, js, and images you may have success with one
media repository with multiple branches.  That way, each branch of
media can be merged or separated where needed.

So the media repository might have folders for css, js, images, swf,
etc.  Anytime you want to make a code change to js used by several
apps, you can merge the changes from trunk to that app's media branch.
 Any time you want to make a code change targeted to a few apps, you
can make a change in a branch and merge to another branch.

Subversion really has the flexibility to complement your development
process, so start by examining your development and deployment
procedures.

- Ken Snyder



More information about the thelist mailing list