我在一家产品开发公司工作。我们先进行内部发布，然后进行公开发布。我想知道其他产品开发公司如何管理其发布？我们如何提供发行编号？标记源代码控制？

解决方案

我们使用SubVersion，在其中创建标记和分支很便宜。

就发行而言，我们遵循以下约定：

(主要版本)(次要版本)(补丁版本)(SVN版本)

• 补丁发布=错误修复
• 次要发行版=二进制兼容/接口兼容
• 主要版本=包含重大更改。

那有意义吗？如果我们需要更多信息，请添加评论，我将编辑我的帖子以进行澄清。

在我的公司中，当发布准备就绪时，我们为主要/次要发布编号创建一个分支，称为" R_2_1"。初始发行是通过在此之后立即创建快照分支或者标签来完成的，称为" R_2_1_0"。当质量检查人员针对发布版本进行错误检查时，会在R_X_Y分支上进行代码更改，然后会创建R_2_1_1分支以标记该版本。所以树看起来像这样：

Mainline
|
|- R_2_1
|  |
|  |-R_2_1_0 (locked)
|  |
|  |
|  |-R_2_1_1 (locked)
|  |
.  .
.  .
.  .

我为一家定制软件提供商工作，当客户认为他们不想实现自己的呼叫中心和网站时，最终演变为解决方案提供商。

在这种环境中，每个主要客户都有机会自定义系统工作方式的某些方面。因此，开发拥有一个核心产品，该产品具有所有合同共有的组件，并且为每个客户提供单独的分支机构(某些客户需要进行细微调整，而其他客户则需要与其他系统进行主要集成)。

一切正常，直到业务增长并且分支机构的数量增加，通常是为了适应真正的me脚变化。在某一时刻，我认为他们在同一代码库中有15种不同的活动版本……这使事情变得非常僵化且难以支持。

不要做我们所做的事情-使发布规模扩大！

我们使用SVN并为每个版本创建两个分支。一个是用于构建此发行版的源代码的标记，另一个是实际发行的二进制文件的新导入。这很重要，因为(无论我们试图使两台开发人员的计算机相同，还是尝试维护稳定的构建计算机)，当我们尝试重新生成X线的X个月后，都不可避免地会发现一些东西已经更改，结果二进制文件也略有不同。

次要补丁是在从发行源分支复制的分支中制作的，并合并到主干中。通过将发布源分支复制到新分支并合并到需要的任何补丁中，可以轻松地进行次要发布。

主要工作在从主干复制的分支中进行，并在完成后合并回主干。然后可以从后备箱中发布主要版本。

基于ITIL框架的答案(或者多或者少等于其他答案)。

ITIL将发布分为三类：主要软件版本，次要软件版本和紧急软件修复。

从ITIL书籍中：

主要软件发行版和硬件升级，通常包含大范围的新功能，其中一些功能可能会使对问题的干预变得多余。主要升级或者发行版通常会取代之前的所有次要升级，发行版和紧急修复程序。
次要软件版本和硬件升级，通常包含一些小的增强功能和修补程序，其中一些可能已作为紧急修补程序发布。较小的升级或者发行版通常会取代之前的所有紧急修复程序。
紧急软件和硬件修复，通常包含对少数已知问题的更正

因此，在此之后我们应该具有：

专业：v1，v2，v3等
次要：v1.1，V2.1等
紧急情况：v1.1.1，v2.1.1等。

就像其他人所说的那样，处理重新分配的最佳方法是分支机构。
我强烈建议我们阅读《 TFS分支指南》(http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785)，其中介绍了根据项目大小和不同项目创建分支结构的几种方法。向最终用户提供软件的方式(主要版本，Service Pack，修补程序)。大部分不是特定于TFS的，因此我们可以将其应用于大多数其他源代码控制系统。

我创建了一个类似的问题，但我想补充一点：我强烈建议使用Jira之类的工具来管理发布周期。我们可以将提交与请求/问题/错误相关联，然后将其标记为发布的一部分。

特别是，如果我们想知道如何管理一个好的发布周期，请查看Apache基金会是如何做到的，因为他们将其归结为一门科学。例如，这是Mahout项目中发布版本的路线图。

连同跟踪问题并将其捆绑在发行包中的工作系统一起，我们将要开始将其与持续集成(我使用过CruiseControl和Hudson)和单元测试进行集成，以便对构建周期和所有内容进行管理别的。