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