假设我有一个带有一些基本功能的Web应用程序。我想推销它。所以我想指定一个版本号 - 类似于0.0.1。我想知道的是，是否有任何限制应该适用于该编号系统？
希望你能提前理解我的问题。
答案 0 :(得分：22)
大多数地方都使用这样的东西：
Major Release.Minor Release.Hot Fix.Build
您的版本号看起来像1.5.0.15等。
答案 1 :(得分：12)
许多免费软件使用三点系统：X.Y.Z其中
这样，版本0.28.1是一个稳定版本，只有一个修复版本，而2.9.0版本是alpha版本，修复程序为零。
有些人也很乐意开发自己的计划。例如。每个版本的Tex关于Pi，版本号：3,3.1,3.14等等。
答案 2 :(得分：9)
这并不重要，只要您可以使用版本号来识别您的版本（即将源代码管理系统的内部版本号添加到版本号中）或使用它来标记您的版本。
执行此操作时，您可能希望将该数字用作第三（或第四）组件。如果某些产品从版本1.12345跳到2.12346，看起来很混乱，但从1.4.12345跳到2.0.12345更常见。
关于开始的号码，我只想引用Eric S. Raymond：
在封闭源世界中，版本 1.0表示“如果你谨慎，不要碰这个。”;在开源世界 它读的更像是“The 开发商愿意打赌他们的 声誉很高。“
答案 3 :(得分：7)
您可以在版本控制中使用您想要的任何数字 - 谁会限制您？
如果你想让你的第一个版本为0.0.0.0.0.0.0.1，那很好，尽管有点傻。如果你想要你的第一个版本是106.3，你也可以这样做，但这有点荒谬。
查看Wikipedia article on Software Versioning了解真实版本编号方案的一些经过验证的想法。
答案 4 :(得分：5)
我一直使用（重写）。（添加功能）。（错误修复）。
但请设置自己的规则并将其公开，以便用户了解它们。
答案 5 :(得分：3)
看看here。 python setuptools对版本编号有一个非常有趣和清晰的规范。我相信你可以从中获得一些非常有见地的提示。
答案 6 :(得分：2)
据我所知，目前还没有任何政府机构决定你如何编号版本。但不要担心，我相信它会很快到来。
同意那些暗示重点小修订的人。我的一般方法是：重大变化得到一个新的主要版本。就像，如果我们添加了重要的新功能。小的变化，如添加一些小便利功能或一个新的报告，得到一个小修改。热门错误修复更改得到修订。
出于简单的营销原因，我肯定会避免将您的第一个发布版本称为“0.l”：小于1.0的数字听起来像初步版本或测试版本。我知道有人打电话给他们的第一个版本2.3或其他一些只是为了让它听起来好像有一段时间来激发更多的信心，尽管这让我觉得有点不诚实。
答案 7 :(得分：2)
如果没有像webmail源代码那样分发给公众的软件怎么样？你认为构建或错误修复号在这种情况下仍然很重要吗？
答案 8 :(得分：1)
版本号不是软件开发中的具体规范。
换句话说，一个团队可能会使用1.0.0.0，其他人可能会使用1.0.0等等。 重要的不是。
选择适合自己的东西。
通常major.minor.revision是最简单直接的使用方法。例如，Visual Studio可以为您自动分配版本号，其他工具也可以。因此，您需要更新的是主要/次要值。构建/修订号自动更新。
答案 9 :(得分：1)
我们使用major.minor.revision.build，其中 revision 是SVN版本，而 build 是基于当前日期的内部版本号（以YYDDD格式，其中 YY 是年份， DDD 是日期编号，因此18001将是2018年1月1日。）
进行SVN修订非常有用，并且不止一次地拯救了我们。
答案 10 :(得分：1)
我用过
Major.Minor.Release.Build 1.02.4.15
以及
Year.Month.Date
2009.12.10
但允许您单独跟踪发布的任何内容都可以。只要你一致。
答案 11 :(得分：1)
我似乎记得在过去（我在这里谈论Commodore）我们使用了类似的语法 release.version.revision 可以附加修复和/或构建，其中修复通常是直接粘贴到修订版的字母。所以一个完整的数字会读起来像：
2.1.44a.786
但是就像大多数人已经说过的那样，这并不重要，没有真正的标准。只需使用最方便的东西。
答案 12 :(得分：1)
您可能需要先查看维基百科上的Software versioning文章，其中提供了有关您所拥有的可能性的一些信息; - ）
它可能会给你一些关于你在特定情况下可以做些什么的想法......
答案 13 :(得分：1)
在阅读了很多文章/ QA /常见问题/书籍后，我开始思考 [MAJOR]。[MINOR]。[REV] 是最有用的版本控制架构 描述项目版本（版本控制架构）之间的兼容性 对于开发人员，不用于营销）。
MAJOR 更改向后不兼容，需要更改 项目名称，文件路径，GUID等。
MINOR 更改向后兼容。马克介绍新的 特征
REV 用于修复安全性/错误。向后和向前兼容。
此版本控制架构受 libtool 版本控制语义和文章的启发：
http://www106.pair.com/rhp/parallel.html
注意：我还建议提供构建/日期/自定义/质量作为附加信息（构建） 编号，构建日期，客户名称，发布质量）：
国家银行， 2011-05-03 ，测试版
但此信息不版本信息!!
答案 14 :(得分：1)
10.50.1600.1
major.minor.build.revision
MAJOR更改向后不兼容，需要更改项目名称，文件路径，GUID等。
MINOR更改向后兼容。标记新功能的介绍。
REV用于安全/错误修复。向后和向前兼容。
例如。在SQL Server 2008中，RTM版本号为10.00.1600.22，而在SQL Server 2012中版本为11.00.2100.60
由于项目名称的变化，即10和11
，第一个字段发生了变化在SQL Server 2008 R2中，RTM版本号为10.50.1600.1，而在SQL Server 2008中版本为11.00.1600.22
由于引入了新功能，第二个字段发生了变化。
第三个字段表示构建（已开发）
Forth字段表示修订，即应用了修补程序......
答案 15 :(得分：0)
您可以使用任何形式的版本编号。
我只是建议使用有意义的东西。 Major.Minor.Revision编号很受欢迎，但您希望的任何编号方案都是“有效”。
答案 16 :(得分：0)
在开发软件库时，I recommend使用版本号来传达两个版本之间的源和二进制兼容性级别。
由于您正在开发Web应用程序，因此两部分版本号可能就足够了。第一部分是新功能，第二部分是修复。