何时将软件版本号从 1.x 增加到 2.x？
我知道关于如何使用（甚至使用）软件版本控制有很多想法。 尽管我想知道软件版本在 1.x 之后什么时候应该变成 2.x。
在我的示例中，我使用 1 和 2，但当然也可以是任何其他数字。
是在完全重写之后吗？或者新的/大部分更新的用户界面？一堆新（主要）功能？重写程序后它的“核心”是什么？
当我查看（可能是一个糟糕的例子）Internet Explorer 或 Chrome 时，我真的无法说出为什么他们如此迅速地增加了他们的“主要”版本......
我现在的想法是，当一个程序从 1.x 升级到 2.x 时。 x，它应该完全重写，至少具有相同的功能，只有更好（更稳定，优化，更清晰的代码等）
有什么想法吗？
I know there are a lot of thoughts about how to use (or even use) software versioning. Even though I would like to know when a software version should become 2.x after being 1.x.
In my example I use 1 and 2, but it could have been any other digit of course.
Is it after a complete rewrite? Or a new/mostly renewed User Interface? A bunch of new (major) features? After a rewrite of the program its 'core'?
When I look to (probably a bad example) Internet Explorer or Chrome I cannot really tell why they have increased their 'major' version so rapidly...
My idea at this moment is that when a program goes from 1.x to 2.x, it should be completely rewritten with at least the same features, only better (more stable, optimized, cleaner code, etc.)
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最终，我们开发的任何东西都是供某人或某物使用的。当某些东西正在使用并且有能力进行更改时，无论使用它的人通常都想知道事物何时发生变化以及变化了多少，以便他们能够为使用它的方式发生任何破坏做好准备。
为此，版本号的目标是快速确定某事物的两个版本（在本例中为软件项目的两个版本）之间的差异范围。
到目前为止，总结如下：
第 2 - 4 点告诉我们，我们的软件应该有一个定义良好的外部接口 (API)，并且我们软件的版本控制系统应该表明当外部接口发生变化时，因为这就是其他人使用。
语义版本控制项目详细说明了具体如何完成此操作的规范。我不会重复规范中的所有内容（实际上，它不是很长），但要点如下：
规范中还有一些更多细节，以及其他理由和基本原理，但这些是要点。
最后，版本号所做的只是提供一种结构化的方式来指示使用该软件的其他实体的更改。只要满足他们的需求并且一致，任何版本控制方案都可以。
Ultimately, anything we develop is for someone or something to use. When something is being used, and has the ability to change, whomever is using it usually wants to know when things change and how much they change so that they can be ready for anything breaking regarding how they are using it.
To this end, the goal of a version number is to quickly determine the scope of the differences between two versions of something (in this case, two versions of a software project).
To summarize so far:
Points 2 - 4 tell us that our software should have a well defined external interface (API), and that the versioning system for our software should indicate when the external interface changes, since that's what other people use.
The Semantic Versioning project details a specification for exactly how this should be done. I won't rehash everything in the specification (really though, it isn't very long), but here's the main points:
There are a few more details in the specification, as well as additional justification and rationale, but those are the main points.
In the end, all a version number does is give a structured way to indicate change to other entities that use the software. As long as you are meeting their needs and are consistent, any versioning scheme is fine.
通常，此类版本更改将表明功能发生重大变化。
我倾向于使用的经验法则是：
1.0 - 2.0（重大变化，大量附加或修改的功能）
1.0 - 1.1（细微变化，一些附加或修改的功能）
1.0 - 1.0.1（错误修复或其他小补丁，核心功能没有变化）
http://en.wikipedia.org/wiki/Software_versioning
Normally such a version change would indicate a major change in functionality.
The rule(s) of thumb I tend to use are:
1.0 - 2.0 (major change, a significant amount of additional or modified functionality)
1.0 - 1.1 (minor change, some additional or modified functionality)
1.0 - 1.0.1 (bug fix or other minor patch, no change in core functionality)
There are several different schemes you can follow that are listed at http://en.wikipedia.org/wiki/Software_versioning
这一切都取决于你，真的。
一些软件（例如 OpenSSL）经过多年的开发才刚刚达到 1.0，而浏览器软件（例如 FireFox 和 IE）似乎经常发布主要版本。
这是一个品味问题。
It's all up to you, really.
Some software, like OpenSSL just hit 1.0 after years of development, while browser software like FireFox and IE seem to be releasing major versions very often.
It's a matter of taste.