|
版本号(version number)
版本号是版本的标识号。 每一个操作系统（或广义的讲，每一个软件）都有一个版本号。 版本号能使用户了解所使用的操作系统是否为最新的版本以及它所提供的功能与设施。 每一个版本号可以分为主版本号与次版本号两部分。 例如：DOS4.0，主版本号是4，次版本号是0。 版本控制比较普遍的 3 种命名格式 : 一、 GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] 英文对照 : Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 示例 : 1.2.1, 2.0, 5.0.0 build-13124 二、 Windows 风格的版本号命名格式 : 主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]] 英文对照 : Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] 英文对照: Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于 0 的整数。 应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。 版本号管理策略 一、 GNU 风格的版本号管理策略： 1．项目初版本时 , 版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0, 如果你为人很低调 , 我想你会选择那个主版本号为 0 的方式 ; 2．当项目在进行了局部修改或 bug 修正时 , 主版本号和子版本号都不变 , 修正版本号加 1; 3. 当项目在原有的基础上增加了部分功能时 , 主版本号不变 , 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉 ; 4．当项目在进行了重大修改或局部修正累积较多 , 而导致项目整体发生全局变化时 , 主版本号加 1; 5．另外 , 编译版本号一般是编译器在编译过程中自动生成的 , 我们只定义其格式 , 并不进行人为控制 . 二、 Window 下的版本号管理策略： 1．目初版时 , 版本号为 1.0 或 1.00; 2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变 , 修正版本号加 1; 3. 当项目在原有的基础上增加了部分功能时 , 主版本号不变 , 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉 ; 4. 当项目在进行了重大修改或局部修正累积较多 , 而导致项目整体发生全局变化时 , 主版本号加 1; 5. 另外 , 编译版本号一般是编译器在编译过程中自动生成的 , 我们只定义其格式 , 并不进行人为控制 . 另外 , 还可以在版本号后面加入 Alpha, Beta, Gamma, Current, RC (Release Candidate), Release, Stable 等后缀 , 在这些后缀后面还可以加入 1 位数字的版本号 . 对于用户来说 , 如果某个软件的主版本号进行了升级 , 用户还想继续那个软件 , 则发行软件的公司一般要对用户收取升级费用 ; 而如果子版本号或修正版本号发生了升级 , 一般来说是免费的 . ， 分为 4 个版本。每个版本有两部分描述，任务，主要描述在此版本阶段需要解决的问题；重点，描述在此阶段需要着重思考的问题。各个版本可以有多次迭代周期，每个迭代周期预计持续时间在 2 ~ 4 周，且时间定量。 1 0.2 版本 项目雏形 1.1 任务 1.1.1 前期可行性分析 1.1.2 基础框架 demo 1.2 重点 1.2.1 确定项目方向及可行性 2 0.5 版本 项目基础框架 2.1 任务 2.1.1 解决高业务量、高风险、影响架构核心问题 2.1.2 确定系统整体结构 2.2 重点 2.2.1 完成核心基础框架，确定架构 3 0.7 版本 项目实现 3.1 任务 3.1.1 实现项目完整功能 3.1.2 整理系统框架 3.2 重点 3.2.1 系统框架结构优化与功能完善 4 0.9 版本 项目优化 4.1 任务 4.1.1 系统框架性能优化 4.2 重点 4.2.1 系统框架性能优化 5 1.0 版本 项目发布 5.1 任务 5.1.1 发布版本 5.2 重点 5.2.1 项目整理 5.2.2 测试解决安全问题 5.2.2.1 SQL 注入 每个版本应该及时得到反馈，反馈结果直接作为确定下一个版本详细计划的依据。 业务需求 功能性 非功能性 RUP 四阶段 初始 细化 构造 移交 SVN 版本控制目录说明 trunk //程序开发主干 branches //分支 tags //tag 版本 doc //文档 design //设计 plan //计划 report //进度报告 |
|
|
