【问题标题】：write incremental number inside a file with grunt用 grunt 在文件中写入增量数字
【发布时间】：2018-03-15 10:22:05
【问题描述】：
我正在想办法让 grunt 在文件上写入增量数字或哈希值。
我有一个名为 config.yml 的文件，其中包含：
version: 0.0.0
每次我更改一些我可以在某处指定的文件（比如所有 .js 和 .css 文件）时，grunt 应该以某种方式增加该数字。
我见过一些缓存破坏插件，但这不是我想要的，因为我不想拥有像 config.987234892374982.yml 或 config.yml?v=1.0.0 这样的东西。我正在寻找一种方法让 grunt 在该文件中找到该数字，以有意义的方式更改它（理想情况下增量，或随机散列），然后保存文件。
你能帮忙吗？非常感谢！
【问题讨论】：
标签：
javascript
gruntjs
versioning
【解决方案1】：
我强烈建议不要针对内部版本号之外的任何内容进行自动版本碰撞。
版本号不仅仅表明您的产品已经构建了多少次。本质上，版本号是对最终用户的语义承诺，涉及与早期版本的兼容性。 Node.js 和 npm 等使用版本控制的系统是围绕 X.Y.Z 版本号包含以下逻辑的核心概念构建的：
- 不具有相同 X 版本的软件将发生严重的重大变化，需要升级（或降级）人员完全重新设计他们使用软件的逻辑，在某些情况下，他们甚至不得不寻找替代方案，因为他们现在正在做的不再起作用了。
- 同一 X 版本中的软件可以相对轻松地更换，而无需对您自己的网站或产品进行全面更改。
- 同一 Y 版本中的软件无需更改任何代码即可更换，因为它应该只是错误修复和安全修复。只有解决已修复问题的代码才需要更改。
- 同一 Z 版本中的软件具有完全相同的来源，因此如果您有 2 个相同 Z.Y.Z 版本的副本，它们可以互换使用。
这是 NPM 和其他包管理器要求所有内容提供商遵守的核心合同。事实上，已经表明，在某些情况下，内容提供者不遵守此版本控制系统，假设语义版本控制适用的此内容的消费者发现他们的构建失败。许多消费者认为，如果 3.5.N 版本有效，则 3.5.X 系列中的任何版本都可以互换，并通过使用 3.5.X 系列的最新版本自动构建他们的代码来利用这一假设。
因此，自动将版本超出内部版本号并不是一个好主意。只有在您实际向公众发布新版本时才应该更新补丁版本，而不是在每次构建之后。仅当您向产品添加了新功能时才应该更新次要版本，而不需要对使用您的产品的软件进行重大更改。仅当您对 API 进行剧烈和破坏性的更改（例如移动和/或删除函数、函数参数、对象或属性）时，才应修改主要版本。