未发布的项目应该收到什么版本号？
注意：我是版本编号的新手。请原谅我的无知。
我有一个项目，其中尝试的主要版本（版本 B）被放弃，然后重新尝试并发布（版本 C）。每个版本都有较前一版本的重大更改，我不认为这是次要更新。版本 B 几乎没有进入版本 C。
版本 A (1.0)
- 开发、发布、更新等。
版本 B (？？？)
- 开发、暂停、放弃。
版本C（2.0）
- 开发，发布，更新等。
我觉得我应该像这样拥有它们的版本，但担心丢失版本的混乱：
- 版本A（1.0）
- 版本B（2.0）
- 版本C（3.0）
Note: I'm new to version numbering. Please excuse my ignorance.
I have a project where an attempted major release (Version B) was abandoned then later re-attempted and release (Version C). Each version has major changes from the previous version that I wouldn't consider an minor update. Little to nothing of Version B made it into Version C.
Version A (1.0)
- Developed, released, updated, etc.
Version B (???)
- Developed, suspended, abandoned.
Version C (2.0)
- Developed, released, updated, etc.
I feel like I should have version them like so, but worried about confusion of the missing version:
- Version A (1.0)
- Version B (2.0)
- Version C (3.0)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您应该有两个版本控制方案。一个内部的，遵循典型的形式：
然后是一个面向公众的。对于面向公众的版本，您可以将内部版本映射到“客户友好”的命名版本。就像围绕 Java 命名策略的热闹一样。
You should have two versioning schemes. An internal one, that follows the typical form:
And then a public facing one. With the public facing one, you can map your internal versions to "customer friendly" named versions. Like the hilarity around Java's naming strategies.
我不介意缺少版本号，除非这是一场营销噩梦。从开发的角度来看，它只是一个指针，一旦超过某个点，以前的版本就只能作为构建未来版本的教训。就像你说的 - 版本 B 几乎没有进入版本 C，所以在内部承认版本 B 的存在有什么意义呢？
营销——有很多公司会跳过版本号。如果客户感到困惑，只需告诉他们您在改进产品方面取得了巨大进步，您跳过了整个版本。另一方面，有时客户会有这样的感觉：如果他们收到软件包的 2.9 版，他们就有权获得 3.0 版的免费副本。毕竟 - 它紧随 2.9 之后。通过 4.0 的命名约定，阻止他们的脚步，并为您的辛勤工作赚取更多的钱。
这也将有助于宣布您的 EOL，允许您终止不存在的版本，而以前的版本听起来就像您是一位王子，因为您主要使用新 EOL 版本的软件的人看起来他们已经是一个版本离开。
这是一场心理游戏——你只需在对手之前控制俄罗斯和中国即可。这就是为什么他们称之为风险。
I wouldn't mind a missing version number unless it is a marketing nightmare. From a development view point it's simply a pointer and once you make it past a certain point the previous versions only served as lessons to build future versions. Like you said - little of Version B made it into Version C so internally what's the point of acknowledging the existence of Version B?
Marketing - there are plenty of companies that will skip a version number. If customer gets confused just tell them you made such great strides in bettering your product you skipped a whole version. The other side is sometimes customers get this feeling that if they receive a version 2.9 of a software package they are entitled to a free copy of version 3.0. After all - it was on the heels of 2.9. Stop them in their tracks and take some more money for your hard work by a naming convention of 4.0.
That also will help with announcing your EOL by allowing you to EOL the non-existent version and previous making it sound like you're a prince since you main people out there with your newly EOL version of software look like they're already one version off.
It's a mind game - you just have to take control of Russia and China before your opponent does. That's why they call it Risk.
多点版本编号是浪费时间。吻。从版本 1 开始，增加 1，并坚持使用整数。如果您使用的系统强制使用额外的句点和数字，请忽略它们。妥善记录每个版本的具体内容、发布时间、发布对象等。仅根据版本号而不是“新增内容”文档来决定是否升级的任何人都不需要担心关于。
Multi-dot version numbering is a waste of time. KISS. Start with version 1, increment by 1, and just stick to whole numbers. If you're using a system forcing extra periods and digits, ignore them. Keep a good log of what's specific to each version, when it was released, to whom it was released, etc. Anyone deciding only by version number and not the "what's new" documentation on whether or not to upgrade is not anyone to be concerned about.
如果版本 B 从未发布，那么您的版本 C 可以发布，公开版本号为 2.0。您不必承认有未成功的内部版本。只要您跟踪映射，您的内部版本号不必与您的公开版本号相匹配。
If Version B was never released, then your Version C can be released with a public release number of 2.0. You don't have to admit to having internal releases that didn't make it. Your internal version number does not have to match your public release numbers, as long as you keep track of the mappings.