> 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.
你也可以指定更細的語義版本范圍。
