我所知道的很多操作系统项目（我是PHP开发人员）都使用版本作为里程碑，但这是最好的方法吗？ 里程碑是否意味着项目迭代过程中的某些事情（有意义的名称）？ 有规则吗？或者它可能是完全主观的？
答案 0 :(得分：4)
就像古老的谚语一样，“关于标准的奇妙之处在于有很多可供选择。”我无法告诉你我将如何为PHP项目做这件事，但我可以告诉你我们用于我们商店的方法 - 这是一个.NET商店。
我们使用相当传统的四部分版本控制系统，版本的每个部分代表不同的东西。例如：
Major.Minor.Revision.Build
显然，每一个都是一个数字。对我们来说，这四个部分是由Microsoft预先确定的。让我向后走过堆栈，看看我们如何证明每一个：
里程碑在哪里玩？它们是我们的项目目标。里程碑是在项目启动前确定的，并代表应达到预期进度水平的点。它主要用于在发布之前向业务用户介绍功能，并监控发布的整体交付计划。我们还在每个里程碑的版本控制中应用了一个标签，以便在需要手动构建任何原因时帮助轻松识别里程碑。
在我们的商店里，里程碑的内容比它的名称更重要。为什么？当有多个原因使其成为里程碑时，复杂的里程碑不能以一种传达意义的方式轻易命名。我们将日程表放在日历和维基上，并描述了预期会在其中实现的内容。
就像我之前提到的，我相信你也会得到其他一些“标准”。我们的目标是找到适合您和您的团队的流程，并坚持下去。
答案 1 :(得分：3)
在我们的开发过程中，版本和里程碑是不同的。 我们的标准里程碑之一是发布。当然，这有一个版本。 但对我来说，一个里程碑是未来的事情，我必须要做的事情。版本与版本相关联，因此它已成为过去的版本。
我们的标准里程碑计划基于公司范围的项目管理标准。我们有
对于迭代开发，我们基本上重复这个循环。 从A到V门是α相，从V到R是β相。对于更大的项目，我们添加与正在完成的特定功能集相关的里程碑。
我们使用它的原因主要是根据这个方案报告所有项目，并且以他们熟悉的方式向管理提供信息总是好的做法; - ）
答案 2 :(得分：1)
是的，这意味着你已经在迭代中完成了足够多的工作来发布有用的东西。里程碑通常意味着您已经获得了比迭代结束更重要的东西。我会使用有意义的名字。
答案 3 :(得分：1)
你说的至少是两个无关的事情。有源代码控制和项目里程碑。他们是相关的，但他们不是一回事。此外，还有软件开发工作本身，它与源代码和项目里程碑有关，但它也有所不同。
这是一种基于Scrum的方法。它有三个不相关的东西，可以编号或命名。
首先，有软件开发工作。
我们有冲刺来构建东西。这些可以编号，但它们通常有名称。名称如“批量加载第1部分”，或“重构工作簿库”或“添加销售演示数据夹具”或类似的东西。
我们有发布内容的版本。这些可以编号（基于SVN修订版，或基于我们的内部“兼容版本”，但它们通常有名称。“客户X的第一版”，或“Bug修复此版本”或“升级到那个”或其他东西有意义。
其次，有源代码控制。为此，我们有一些内部版本/修订版跟踪，与sprint和release没什么关系。
SVN拥有存储库版本号。每次签入都会增加。几个星期，每天都有签到。几个星期以来，只有一些“大”签到。
我们有一个major.minor版本号，我们手动更新以显示兼容性。一些应用程序从1.1移动到1.2，因为一些小的变化，但数据库和API是相同的。其他应用程序从2.3移动到3.1，因为数据库或API（或两者）以某种不兼容的方式发生了变化，我们需要进行模式迁移，并可能通知客户对REST客户端界面的更改。
第三，有项目规划。
我们的项目规划里程碑包括我们的发布时间表。但是，项目里程碑包括其他与软件无关的事情。里程碑包括诸如“签署新的托管协议”之类的内容，或“获取客户X测试数据”。这些不是版本或发行版或冲刺或任何东西。
“有规则吗？”是。阅读Scrum以获取一系列规则。
这不是一件事。这是两（或三）件事。
答案 4 :(得分：0)
版本号很方便，因为您可以立即使用任何两个版本，看看哪一个是两者中较新的版本。它在某种程度上总是主观的，因为谁说什么特征或错误修复构成了里程碑？
我喜欢的方案是x.y.z，其中x是主要版本号，y是次要版本号，z是内部版本号。主要版本将意味着重写，大修或主要新功能的引入。次要版本将意味着重大错误修复，或一些小功能改进或错误修复。构建编号正好是构建数量。