软件项目版本号的命名规则及格式介绍

软件项目版本号的命名规则及格式介绍

责任编辑:李倩作者: ITPUB论坛   2009-05-01   
文本Tag: 版本管理

【IT168 技术文章】

    版本控制比较普遍的 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 位数字的版本号 .

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
xxx有限公司的软件产品研发版本管理规范旨在确保软件产品的开发、测试、发布和维护过程的有序进行,保障软件质量和项目进度的同时提高开发团队的协作效率和管理能力。具体规范如下: 1. 版本规范:各个版本应按照一定规则命,如主版本号.次版本号.修订版本号.编译版本号。主版本号表示重大功能更新、接口变更或不兼容的改动;次版本号表示小功能的增加;修订版本号表示已发布功能的修复和优化,编译版本号表示编译的次数。 2. 版本控制工具:使用专业的版本控制工具,如Git或SVN,保证源代码的管理和团队协作的可行性。每个版本的代码均保存在版本控制系统中,方便团队成员跟踪修改、恢复上一个版本等操作。 3. 分支管理规范:对于大型软件项目,应建立主干分支、开发分支和发布分支。主干分支用于长期稳定版本的维护,开发分支用于日常的开发工作,发布分支用于发布前的测试和bug修复。 4. 版本发布流程:严格按照版本发布流程进行发布管理。包括需求分析、设计、编码、测试、上线等环节,每个环节都要有相应的质量控制措施,确保版本的可用性和稳定性。 5. 版本迭代周期:制定明确的版本迭代周期,根据项目和市场需求进行相应的调整。迭代周期既要保证版本发布的及时性,又要保证开发团队有充足的时间进行需求分析和测试等工作。 6. 文档管理规范:对版本相关的文档进行合理的归档和管理,包括需求文档、设计文档、测试用例等。所有文档都应进行版本控制,确保文档与软件版本一致性。 7. 变更控制规范:对于需求变更和bug修复等版本变更请求,应建立完善的变更控制机制,包括变更申请、评审、测试、上线等环节,避免未经检验的变更带来风险。 8. 团队协作规范:每个开发团队成员应遵守相应的代码规范,保证代码质量和可读性。团队需要定期开展代码审查和知识分享,提高整个团队的技术水平和合作效率。 通过遵守上述规范,xxx有限公司能够更好地管理软件产品版本开发和发布过程,提高产品质量和团队效率,同时确保项目能够按时交付和满足客户需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值