> Semantic versioning is a standard that a lot of projects use to communicate what kinds of changes are in this release. It's important to communicate what kinds of changes are in a release because sometimes those changes will break the code that depends on the package. 语义化版本控制是一种标准，许多项目都用它来标识新版本是何种更改。这是非常重要的，因为有时这些更改会破坏依赖这个包的代码。 ## 语义化版本对于发布者 > If a project is going to be shared with others, it should start at **1.0.0**, though some projects on npm don't follow this rule. 如果项目将要与他人分享，那它的版本应该始于**1.0.0**，尽管npm上有些项目不遵循此规则。 > After this, changes should be handled as follows: 之后，所有更改应该按如下方法处理： > Bug fixes and other minor changes: Patch release, increment the last number, e.g. 1.0.1 New features which don't break existing features: Minor release, increment the middle number, e.g. 1.1.0 Changes which break backwards compatibility: Major release, increment the first number, e.g. 2.0.0 * Bug修复和其他小版本修改：用Patch版本，增加最后的版本数，如：1.0.1； * 不会破坏已有特性的新特性：用Minor版本，增加中间的版本数，如：1.1.0； * 会破坏向后兼容的更改：用Majo版本，增加第一个版本数，如：2.0.0. ## 语义化版本对于使用者 > As a consumer, you can specify which kinds of updates your app can accept in the **package.json** file. 如果你是包的使用者，你可以在`package.json`文件中指定你的app能接受哪种版本。 > If you were starting with a package 1.0.4, this is how you would specify the ranges: 如果你用某包的1.0.4版本开始开发的，你可以按下面方式指定版本范围： * 补丁版本（Patch releases）: 1.0 or 1.0.x or ~1.0.4 * 次版本（Minor releases）: 1 or 1.x or ^1.0.4 * 主版本（Major releases）: * or x > You can also specify more granular semver ranges. 你也可以指定更细的语义版本范围。