grunt-rev 的默认行为是评估给定资源并将内容的哈希值放入路径中，因此 /images/sprites/rewards.png 变为 /images/sprites/f936712a.rewards.png
我不想要那个。我同时提供了几个修订版本，我希望能够随意删除旧版本，所以我想将其重命名为 /2013-06-10-e75607/images/sprites/rewards.png （其中 e75607是整个修订的提交 ID，与单个文件无关）。
这是 grunt-rev 和 grunt-usemin 的可能性吗？有没有等效的工具可以做到这一点？
编辑
有几个人问我为什么不使用每个文件的哈希值。让我解释：
在老式网站中，为了响应几乎所有用户输入，浏览器会重新加载，后端会根据输入生成一个全新的页面，HTML 被发送到浏览器，浏览器会显示该页面。这是一个缓慢的、CPU 和带宽密集型的过程，但它确实有一个优势：所有加载的资产都在几秒钟内一起加载。
在更现代的网站中，加载的页面描述了整个应用程序。当用户进行一些输入时，页面上的 Javascript 会根据需要呈现新的 DOM 元素并加载新的资产。整个页面很少或从不重新加载结果该站点的响应速度大大提高（并且更容易开发，更安全，运行成本更低，等等）但具有相应的缺点：资产可能会加载数小时或页面加载后的几天。
假设您在上午 10 点访问该站点，该站点运行的是 cd1d0906 版本。10:30，站点升级到版本4b571377。上午 11 点，您按下一个按钮，该按钮会弹出一个名为 sprite.png 的图像呈现的弹出窗口。显然，您需要 sprite.png 的 cd1d0906 版本——而不是 4b571377 版本。
因此，维护良好的站点将在版本更改后的几天内继续提供所有资产的旧版本。最简单的方法是将所有资产保存在以版本命名的目录中。
这种“不必要地”丢弃未更改文件的缓存条目的抱怨是相当不可信的。大多数部署的资产是 CSS 文件、JS 文件和 sprite，所有这些都是许多较小文件的编译。这是一种罕见的部署，不会更改一个CSS 文件、一个JS 文件和一个精灵图像。版本更改后，缓存很少有价值。