> Picture an existing application that's been deployed using Tapestry > 5.1.0.5; the prototype.js is exposed to the client as > /assets/scriptaculous/5.1.0.5/prototype.js. > > Now the application is rebuild with tapx-prototype and redeployed. > Without the remapping, the URL would be unchanged and some clients > would continue to use the old prototype.js. > > With the new contribution, the URL will now be > /assets/tapx-prototype/1.6.1/prototype.js which will force the browser > to reload.
Right, I understand now - thanks. So we don't need this since we've not released yet and it'll only change again if we upgrade T5 versions. > That being said, I'm finding the current version number system too > complicated. Rather than hide assets behind a mish-mash of application > version numbers, library version numbers and Tapestry's version > number, I'm thinking of simplifying it to be just the application > version number. So all asset URLs would be /asset/XYZ/... where XYZ > was the application version number. That means that on an update to > the application, clients would have to download a fresh copy of > prototype.js, tapestry.js, etc. (the core Tapestry stack) but it would > be harder to screw up some of these other path & version number > details. I like it the way it is personally, seems elegant and efficient. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
