语义版本控制特别适用于具有公共 API 的项目，但通常也适用于具有“重大变更”替代概念的其他环境，例如对 GUI 界面的重大变更。
The Semantic Versioning 2.0.0 standard provides the 0.y.z space to indicate that your project does not have a stable public API:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
It is suggested to start at 0.1.0 and bump the minor version on every breaking change to the public API. You can increment to 1.0.0 when you are in a position to appropriately control and manage these breaking changes:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
The benefit of using the 0.y.z space is that you will not reach a high major version, e.g. 142.6.0, during initial development. It tends to be industry convention to avoid high major version numbers, partially for marketing reasons, but this may not be relevant to you.
Semantic Versioning applies specifically to projects with public APIs, but is often applied in other contexts with an alternative notion of "breaking change", e.g. large changes to GUI interfaces.
The version number is entirely up to you. Do what makes sense to you and be consistent. Nobody says you have to start from 0, or 0.0, or 1.0, or 1.1.
Great programmers have actually used the version numbering system as local jokes. Examples (Wikipedia):
Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.1415926; it was last updated in March 2008
For METAFONT:
Metafont has a versioning system similar to that of TeX, where the number asymptotically approaches e with each revision.
Finally, not quite a version number, but equally interesting, is that Google's initial public offering (IPO) was filed with the SEC for raising $2,718,281,828 (notice that e~2.718 281 828).
My point is: don't feel that you need to follow the crowd. Be creative and consistent.
I think different factors come into play here. Psychological/marketing impact of the version number (version number increased often => more $$$, people don't want to buy a 0.99 beta version, etc) must be taken into account. "Logic" version numbers can help when working in a huge team.
And I like the linux way of having odd numbers for the unstable versions, and even numbers for the stable one.
0.1.0 是我开始并从那里升级的版本。这是我为 Adrian 的 Xploration 改编的，尽管在我早年我非常零星地使用过 1.0.0、0.0.1 和其他一些版本。但我确实建议从 0.1.0 开始并从那里开始。
根据 Semver，在 abc 中保留 a 和 c 为 A. 你的第一个正式版本和 C. 错误修复和补丁。这是因为主要版本通常会破坏旧代码。补丁只是修复错误。这完全是个人喜好，0.99.0 并不意味着您必须转到 1.0.0 等。我见过一些一直到 0.218.42。
0.1.0 is what I start with and move up from there. This is what I've adapted for Xploration By Adrian, although in my early years I was very sporadic and used 1.0.0, 0.0.1, and a few others. But I do recommend starting at 0.1.0 and going from there.
Per Semver, reserve a and c in a.b.c for A. You first official release and C. Bug fixes and patches. This is because a major version generally breaks older code. And patches simply fix bugs. This is all personal preference, 0.99.0 doesn't mean you have to go to 1.0.0, etc. I've seen some that go all the way to 0.218.42.
Typically, the versioning has some meaning to the programmer. Increasing the major number might indicate large changes that prevent backwards-compatibility. Other numbers in the version number might indicate smaller feature enchancements or bug fixes.
If you are worried version 0.6.5 has an incomplete ring to it, you might want to market it under version 1.0. Your marketing version number need not match your internal version number. The version number of Windows 7, for instance, is 6.1.
My personal preference is to start from 0.1.0 and go from there.
Depends on the project. For simple command line tools, I usually start around 0.9[.0] since I only consider releasing or packing them when they're near completion (or ready for beta testing, anyway.) More complicated projects start around 0.1[.0] and some never even see 1.0. I consider 1.0 a release version (or at least a locally tested beta or release candidate) and plan accordingly.
With team projects, whoever puts the first version tag gets to decide :).
The version numbers should be meaning to you as Arrieta correctly commented before.
Maybe following something like: First # is mayor release, Second # is the same mayor release with some features added and Third # is the same mayor release, with the same features but with fixed bugs or added little (but significant enough) changes.
1.3.2 => 1st Release, with more features and some bugs fixed.
However, for final users, some are used to big numbers for final releases.
For instance: Corel 8, for 8.0.0, 8.0.1, 8.2.2, etc. Corel 9, for 9.0.0...etc.
And mostly is more about marketing strategies like: Corel X5 instead of Corel 15.0.2 for instance.
I would say that it depends whether the version number is for you or for the client.
When I get my first usable ready but not feature complete version, I normally try to judge how far along it is towards a feature complete version, so for example if my first usable is 33% feature complete I make the version number 0.3.0 or similar. Then as I move towards feature complete corresponding versions get given numbers in a similar way.
But once you move on past feature complete versioning needs to change
发布评论
评论（11）
语义版本控制 2.0.0 标准提供 0.yz 空间来指示您的项目没有稳定的公共 API：
建议从 0.1.0 开始，并在公共 API 的每次重大更改时升级次要版本。当您能够适当地控制和管理这些重大更改时，您可以增量到 1.0.0：
使用 0.yz 空间的好处是，在初始开发过程中您不会达到较高的主要版本，例如 142.6.0。行业惯例往往是避免高主要版本号，部分原因是出于营销原因，但这可能与您无关。
语义版本控制特别适用于具有公共 API 的项目，但通常也适用于具有“重大变更”替代概念的其他环境，例如对 GUI 界面的重大变更。
The Semantic Versioning 2.0.0 standard provides the 0.y.z space to indicate that your project does not have a stable public API:
It is suggested to start at 0.1.0 and bump the minor version on every breaking change to the public API. You can increment to 1.0.0 when you are in a position to appropriately control and manage these breaking changes:
The benefit of using the 0.y.z space is that you will not reach a high major version, e.g. 142.6.0, during initial development. It tends to be industry convention to avoid high major version numbers, partially for marketing reasons, but this may not be relevant to you.
Semantic Versioning applies specifically to projects with public APIs, but is often applied in other contexts with an alternative notion of "breaking change", e.g. large changes to GUI interfaces.
版本号完全由您决定。做对你来说有意义的事情并保持一致。没有人说你必须从 0、0.0、1.0 或 1.1 开始。
伟大的程序员实际上已经将版本编号系统用作当地的笑话。示例（维基百科）：
对于 METAFONT：
最后，虽然不完全是版本号，但同样有趣的是，Google 的首次公开募股 (IPO) 已向 SEC 提交，筹集资金 2,718,281,828 美元（请注意 e~2.718 281 828）。
我的观点是：不要觉得你需要随波逐流。要有创意并保持一致。
The version number is entirely up to you. Do what makes sense to you and be consistent. Nobody says you have to start from 0, or 0.0, or 1.0, or 1.1.
Great programmers have actually used the version numbering system as local jokes. Examples (Wikipedia):
For METAFONT:
Finally, not quite a version number, but equally interesting, is that Google's initial public offering (IPO) was filed with the SEC for raising $2,718,281,828 (notice that e~2.718 281 828).
My point is: don't feel that you need to follow the crowd. Be creative and consistent.
我认为不同的因素在这里发挥作用。必须考虑版本号的心理/营销影响（版本号经常增加 => 更多 $$$，人们不想购买 0.99 beta 版本等）。在大型团队中工作时，“逻辑”版本号会有所帮助。
我喜欢 Linux 的方式，奇数表示不稳定版本，偶数表示稳定版本。
I think different factors come into play here. Psychological/marketing impact of the version number (version number increased often => more $$$, people don't want to buy a 0.99 beta version, etc) must be taken into account. "Logic" version numbers can help when working in a huge team.
And I like the linux way of having odd numbers for the unstable versions, and even numbers for the stable one.
为
npm包选择版本号时，请注意对于package.jsonsemver 范围 在 v1.0.0 以下不起作用。也就是说，相当于
如果您希望能够使用 semver 范围，或者您想让其他人使用它们，您可能希望从 1.0.0 开始
When choosing version numbers for an
npmpackage, be aware that for dependencies listed inpackage.jsonsemver ranges won't work below v1.0.0. That is,is equivalent to
If you want to be able to use semver ranges, or you want to let other people use them, you might want to start with 1.0.0
0.1.0 是我开始并从那里升级的版本。这是我为 Adrian 的 Xploration 改编的，尽管在我早年我非常零星地使用过 1.0.0、0.0.1 和其他一些版本。但我确实建议从 0.1.0 开始并从那里开始。
根据 Semver，在 abc 中保留 a 和 c 为 A. 你的第一个正式版本和 C. 错误修复和补丁。这是因为主要版本通常会破坏旧代码。补丁只是修复错误。这完全是个人喜好，0.99.0 并不意味着您必须转到 1.0.0 等。我见过一些一直到 0.218.42。
0.1.0 is what I start with and move up from there. This is what I've adapted for Xploration By Adrian, although in my early years I was very sporadic and used 1.0.0, 0.0.1, and a few others. But I do recommend starting at 0.1.0 and going from there.
Per Semver, reserve a and c in a.b.c for A. You first official release and C. Bug fixes and patches. This is because a major version generally breaks older code. And patches simply fix bugs. This is all personal preference, 0.99.0 doesn't mean you have to go to 1.0.0, etc. I've seen some that go all the way to 0.218.42.
通常，版本控制对程序员有一定的意义。增加主编号可能表示存在阻止向后兼容性的较大更改。版本号中的其他数字可能表示较小的功能增强或错误修复。
如果您担心 0.6.5 版本的功能不完整，您可能想在 1.0 版本下销售它。您的营销版本号不需要与您的内部版本号匹配。例如，Windows 7的版本号是6.1。
我个人的偏好是从 0.1.0 开始并从那里开始。
Typically, the versioning has some meaning to the programmer. Increasing the major number might indicate large changes that prevent backwards-compatibility. Other numbers in the version number might indicate smaller feature enchancements or bug fixes.
If you are worried version 0.6.5 has an incomplete ring to it, you might want to market it under version 1.0. Your marketing version number need not match your internal version number. The version number of Windows 7, for instance, is 6.1.
My personal preference is to start from 0.1.0 and go from there.
取决于项目。对于简单的命令行工具，我通常从 0.9[.0] 左右开始，因为我只考虑在它们接近完成时发布或打包它们（或者准备好进行 Beta 测试）。更复杂的项目从 0.1[.0] 左右开始，有些甚至从未见过 1.0。我认为 1.0 是一个发行版本（或者至少是本地测试的测试版或候选版本）并进行相应的计划。
对于团队项目，谁放置第一个版本标签就可以决定:)。
Depends on the project. For simple command line tools, I usually start around 0.9[.0] since I only consider releasing or packing them when they're near completion (or ready for beta testing, anyway.) More complicated projects start around 0.1[.0] and some never even see 1.0. I consider 1.0 a release version (or at least a locally tested beta or release candidate) and plan accordingly.
With team projects, whoever puts the first version tag gets to decide :).
版本号对您来说应该有意义，正如 Arrieta 之前正确评论的那样。
也许遵循这样的内容：第一个 # 是市长版本，第二个 # 是相同的市长版本，添加了一些功能，第三个 # 是相同的市长版本，具有相同的功能，但修复了错误或添加了很少（但足够重要）的更改。
1.3.2 =>第 1 版，具有更多功能并修复了一些错误。
然而，对于最终用户来说，有些人习惯了最终版本的大数字。
例如：
Corel 8，适用于 8.0.0、8.0.1、8.2.2 等。
Corel 9，9.0.0...等。
主要是更多关于营销策略，例如：Corel X5 而不是 Corel 15.0.2。
我想说这取决于版本号是给你的还是给客户的。
The version numbers should be meaning to you as Arrieta correctly commented before.
Maybe following something like: First # is mayor release, Second # is the same mayor release with some features added and Third # is the same mayor release, with the same features but with fixed bugs or added little (but significant enough) changes.
1.3.2 => 1st Release, with more features and some bugs fixed.
However, for final users, some are used to big numbers for final releases.
For instance:
Corel 8, for 8.0.0, 8.0.1, 8.2.2, etc.
Corel 9, for 9.0.0...etc.
And mostly is more about marketing strategies like: Corel X5 instead of Corel 15.0.2 for instance.
I would say that it depends whether the version number is for you or for the client.
当我准备好第一个可用但不是功能完整的版本时，我通常会尝试判断它离功能完整版本还有多远，因此，例如，如果我的第一个可用功能完成了 33%，我会将版本号设置为 0.3.0 或相似的。然后，当我朝着功能完整的方向发展时，相应的版本会以类似的方式获得给定的数字。
但是一旦你继续使用过去的功能，完整的版本控制就需要改变
When I get my first usable ready but not feature complete version, I normally try to judge how far along it is towards a feature complete version, so for example if my first usable is 33% feature complete I make the version number 0.3.0 or similar. Then as I move towards feature complete corresponding versions get given numbers in a similar way.
But once you move on past feature complete versioning needs to change
从 0.0.0 开始，然后从那里继续。
start with 0.0.0 and move on from there.
从 1.1.1 开始，然后继续。
Start with 1.1.1 and move on from there.