软 件 版 本

1 按软件研发版本划分

Alpha——————-内部测试版
Beta——————–外部测试版
Demo——————-演示版
Preview—————–预览版
RC———————–发布倒记时
RTM———————发布到生产商
Full———————–完全版
Mini———————-迷你版
Enhance—————-增强版
Plus———————-增强版（一般只做程序界面及多媒体功能上的修改）

2 按软件授权划分

Free———————-免费版
Trail———————-试用版
Shareware————–共享版
Release—————–发行版（有时间限制）
Upgrade—————–升级版
Retail———————零售版
Regged——————已注册版

3 按用户类型划分

Express——————特别版
Deluxe——————-豪华版

软件的版本 变更有什么原则/strong>

为了维护软件项目, 我们提出了对版本进行管理控制的要求. 而对于用户来说, 版本直接体现在版本 的命名上. 那么, 如何对版本 进行命名呢下面, 让我们看一下比较普遍的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]]

GNU 风格的版本 管理策略

当项目初版本时, 版本 可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0, 如果你为人很低调, 我想你会选择那个主版本 为 0 的方式;
当项目在进行了局部修改或 bug 修正时, 主版本 和子版本 都不变, 修正版本 加 1;
当项目在原有的基础上增加了部分功能时, 主版本 不变, 子版本 加 1, 修正版本 复位为 0, 因而可以被忽略掉;
当项目在进行了重大修改或局部修正累积较多, 而导致项目整体发生全局变化时, 主版本 加 1;
另外, 编译版本 一般是编译器在编译过程中自动生成的, 我们只定义其格式, 并不进行人为的控制.

Window 下的版本 管理策略

当项目初版时, 版本 为 1.0 或 1.00;
当项目在进行了局部修改或 bug 修正时，主版本 和子版本 都不变, 修正版本 加 1;
当项目在原有的基础上增加了部分功能时, 主版本 不变, 子版本 加 1, 修正版本 复位为 0, 因而可以被忽略掉;
当项目在进行了重大修改或局部修正累积较多, 而导致项目整体发生全局变化时, 主版本 加 1;
另外, 编译版本 一般是编译器在编译过程中自动生成的, 我们只定义其格式, 并不进行人为的控制.
另外, 还可以在版本 后面加入 Alpha, Beta, Gamma, Current, RC (Release Candidate), Release, Stable 等后缀, 在这些后缀后面还可以加入 1 位数字的版本 .

对于用户来说, 如果某个软件的主版本 进行了升级, 用户还想继续那个软件, 则发行软件的公司一般要对用户收取升级费用; 而如果子版本 或修正版本 发生了升级, 一般来说是免费的.