我在一家产品开发公司工作。我们首先做内部发布，然后是公开发布。我想知道，其他产品开发公司如何管理他们的发布？你如何给出发行号码？标记源代码管理？
答案 0 :(得分：12)
我们使用SubVersion，其中标签和分支很便宜。
就版本而言，我们遵循以下惯例：
（主要版本）。（次要版本）。（补丁发布）。（SVN修订版）
这有意义吗？如果您需要更多信息，请添加评论，我将编辑我的帖子以澄清。
答案 1 :(得分：3)
I created a similar question，但我想补充一点：我强烈建议使用类似Jira的内容来管理发布周期。您可以将提交与请求/问题/错误相关联，然后将这些提交标记为发布的一部分。
特别是如果你想知道如何管理一个好的发布周期，看一下Apache基金会如何做到这一点，因为他们将它归结为科学。例如，这是roadmap for releases in the Mahout project。
除了跟踪问题并将其捆绑在发布包中的工作系统之外，您还需要开始将其与持续集成（我已使用CruiseControl和Hudson）以及单元测试集成，以便管理您的构建周期以及其他一切。
答案 2 :(得分：2)
我为一家定制软件提供商工作，当客户认为他们不想实施自己的呼叫中心和网站时，他们最终变成了解决方案提供商。
在该环境中，每个主要客户都有机会定制系统工作方式的某些方面。因此，开发有一个核心产品，其中包含所有合同共有的组件，以及每个客户的独立分支（一些客户需要进行小的调整，其他客户则与其他系统进行主要集成）。
它运作良好，直到业务增长和分支机构数量扩大，通常是为了适应真正的蹩脚变化。有一次，我认为他们有相同代码库的15种不同的活跃版本...这使得事情变得非常灵活，难以支持。
不要做我们做的事情 - 让你的发布规模扩大！
答案 3 :(得分：2)
正如其他人所说，处理管理升级的最佳方法是分支。 我强烈建议您查看TFS分支指南（http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785），该指南介绍了根据项目规模创建分支结构的几种方法以及向最终用户提供软件的不同方法（主要版本，服务）包，修补程序）。大部分内容并非特定于TFS，因此您可以将其应用于大多数其他源代码控制系统。
答案 4 :(得分：1)
在我的公司，当发布版准备就绪时，我们会为主要/次要版本号创建一个分支，称为R_2_1。初始版本通过在之后立即创建快照分支或标签来完成，称为R_2_1_0。当QA文件针对某个版本发生错误时，会在R_X_Y分支上进行代码更改，然后会创建一个R_2_1_1分支来标记该版本。所以树看起来像这样：
Mainline
|
|- R_2_1
| |
| |-R_2_1_0 (locked)
| |
| |
| |-R_2_1_1 (locked)
| |
. .
. .
. .
答案 5 :(得分：1)
我们使用SVN并为每个版本创建两个分支。一个是用于构建此版本的源代码的标记，一个是实际发布的二进制文件的新导入。这很重要，因为（无论你试图使两个开发人员的机器相同，或者尝试维护稳定的构建机器），当你试图在6个月后重新构建X时，你会发现已经改变，结果的二进制略有不同。
在从发布源分支复制的分支中生成次要补丁，并将其合并到主干中。然后可以通过将发布源分支复制到新分支并合并所需的补丁来轻松地发布次要版本。
主要工作在从主干复制的分支中执行，并在完成时合并回主干。然后可以从主干发布主要版本。
答案 6 :(得分：1)
基于ITIL框架的答案（或多或少与其他框架相同）。
ITIL将发布分为3组：主要软件版本，次要软件版本和紧急软件修复程序。
来自ITIL书籍：
•主要软件版本和硬件升级，通常包含大量新功能，其中一些可能会对冗余问题进行干预。主要升级或发布通常取代所有先前的次要升级，发布和紧急修复 •次要软件版本和硬件升级，通常包含小的增强功能和修复程序，其中一些可能已作为紧急修复程序发布。次要升级或发布通常会取代之前的所有紧急修复程序 •紧急软件和硬件修复，通常包含对少数已知问题的更正
所以，接下来你应该：
专业：v1，V2，v3等
轻微：v1.1，V2.1等
紧急情况：v1.1.1，V2.1.1等。
答案 7 :(得分：0)
co-cat关于TFS的回答的后续行动。有一个新的URL，包含VS2010和VS11的一些更新