在拟定《配置管理规范》时，需要考虑很多因素。本文例举一些需要考虑的因素以及相关的可选策略。

出发点

出发点的不同决定后续一系列选择的不同。配置管理的出发点可以分为两种：

以开发管理为出发点

常见于乙方（服务提供方）。乙方的配置管理目的是：
- 管理各阶段的可构建物，如源代码、配置参数、设计文档、构建脚本等
- 实现不同团队的并行开发
以运维为出发点

常见于甲方（服务使用方）。甲方的配置管理目的是：
- 管理各阶段的可部署物，随时可以从配置库中获取需要的某个版本进行部署
- 管理打补丁、升级等运维操作
- 记录当前的部署情况

配置管理一般都通过“版本”来标记某一个时点、某一条路径上的某种状态。由于甲方和乙方配置管理的目的和出发点不同，二者对“版本”内涵的理解可能有所不同：

乙方关注的“版本”，是开发过程中的一个状态。其配置项是源代码、配置参数、设计文档、构建脚本等内容，
基于这些内容开发人员可以获取工程的基线、进行新特性的开发或bug修复，最终产生下一个版本。
甲方关注的“版本”，是软件生命周期中的一个状态。其配置项是包括安装包、补丁包、部署说明等部署内容，是自开发过程中发布的产物。
基于这些内容，运维人员可以获取可部署版本、进行部署、打补丁或升级，最终产生一个可用的环境。

版本命名

版本命名就是为某一个版本取一个符合某种规律的名称，通过该名称相关人员可以明确知道所对应的状态、与其他版本的关系，而不需要过多的解释。

版本的命名需要遵循某种格式。目前被普遍接受的是GNU风格的版本号格式：

主版本号.子版本号[.修正版本号 [-发布版本号]]

主版本号(Major)

使用递增的整数，主版本号的变化表明重大的升级，一般不向下兼容。

GNU项目一般主版本号从 0 开始；M$风格的项目主版本号从 1 开始。
次版本号(Minor)

使用递增的整数。次版本号的变化表明增加了新特性(feature)或修正了较多的bug，但是能够向下兼容。

当主版本号升级时，此版本号一般会归零。
修正版本号(Revision)

使用递增的整数，用于标记少量bug的修复。初始可以不标记修正版本号，也可以标记为
=0=。

通常，修正版本号来自于某个“hotfix”的开发，而不是完整的工程。
发布版本号(Release)

一般用于持续集成等需要多次发布的场景。编译版本号的格式为：

发布类型顺序号

其中常用的发布类型包括：
- alpha: 内部测试版，用于开发者或专业人员测试，通常bug较多
- beta: 外部测试版，bug较少，可以由用户参与测试
- build: 构建版本，用于持续集成
- current: 当前(最新)版
- release: 发布版，正式版本
- update: 升级版，一般用于标记升级包

版本号举例如下：

现代的版本管理工具都支持多个路径的并行开发。其中一个最主要的路径称为“主干”，比如比如svn中的
trunk=，或者git中的 =master 分支；
相对于“主干”，其余的路径称为“分支”(branches)。

通常，会按照开发的目的划分分支，比如：

所谓主干策略，就是选择主干上记录什么样的版本：

确定分支策略，首先要确定“主干策略”，即将哪种版本记入主干：

稳定主干策略

在主干上记录发布版本，在分支上进行新功能的开发和bug修复。

分支上的开发和测试完成后，需要发布时，再合并到主干。同时，主干上的每个版本都会给出一个版本命名(一般通过标签tags）。
不稳定主干策略

在主干上记录（最新）开发版本，其他分支用于测试、发布等。

这种方式分支合并的工作量较小，但是管理不够严格，适合非常小型、非正式的项目，比如文档资料的管理。

决定了“主干策略”，还需要决定哪些情况可以创建分支，分支的存在周期，以及在什么情况下进行哪些分支的合并。

这里
有一个很好的分支模型，尽管是基于git描述的，但也可以在svn上使用。该模型的全貌如下图：

不管是出于开发管理还是运维管理，都可以直接使用这个分支模型。当然，也可以根据自己的需要进行剪裁。

版本库不仅仅是开发人员使用，实际上，版本库可以成为开发人员、测试人员、运维人员协同的平台和基础，由配置管理员进行管理和协调。

与版本库相关的软件过程包括配置管理、质量管理、变更管理、发布管理等，涉及到版本库初始化、开发、升级、发布、部署、hotfix等诸多的流程。

在《配置管理规范》中，还要明确每个流程中，各角色的职责和具体的步骤。

配置项清单用于规范哪些内容需要纳入版本管理，以及组织这些内容的目录结构。

如果使用subversion进行管理，顶层目录通常分为 trunk， branches,
tags 三个子目录，分别管理主干、分支和标签。