软件版本命名规则真实性声明
软件版本命名规范及详细解释.docx
1、版本命名规范软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、release。
2、软件版本阶段说明Base：此版本表示该软件仅仅是一个基础功能，通常包括所有将要编写的功能，但是功能都没有做完整的实现，只是做为软件整体的一个基础架构。
Alpha：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。
测试人员提交Bug经开发人员修改确认之后，发布到测试xx让测试人员测试，此时可将软件版本标注为alpha版。
Beta：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。
修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为beta版。
RC：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。
Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。
该版本有时也称标准版。
3、版本号修改规则（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。
此版本号由项目决定是否修改。
（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。
此版本号由项目决定是否修改。
（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
（4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
【2017年整理】医疗器械软件注册技术审查指导原则
医疗器械软件注册技术审查指导原则本指导原则旨在指导制造商提交医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求。
本指导原则是对医疗器械软件的一般性要求，制造商应根据医疗器械软件的特性提交注册申报资料，判断指导原则中的具体内容是否适用，不适用内容详述理由。
制造商也可采用其他满足法规要求的替代方法，但应提供详尽的研究资料和验证资料。
本指导原则是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技术报告制定的。
随着法规和标准的不断完善，以及认知水平和技术能力的不断提高，相关内容也将适时进行修订。
本指导原则是对制造商和审查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在遵循相关法规的前提下使用本指导原则。
本指导原则针对软件的特殊性，在现行法规要求下进一步明确了对医疗器械软件的要求，特别是对软件更新、软件版本的要求。
本指导原则是医疗器械软件的通用指导原则，其他涉及软件医疗器械产品的指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。
一、范围本指导原则适用于医疗器械软件的注册申报，包括第二类、第三类医疗器械产品，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。
医疗器械软件包括独立软件和软件组件。
独立软件：作为医疗器械或其附件的软件；软件组件：作为医疗器械或其部件、附件组成的软件。
独立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台。
独立软件包括通用型软件和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如PACS、中央监护软件等；而专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用，如Holter数据分析软件、眼科显微镜图像处理软件等。
软件组件应同时具备以下两个特征：具有一个或多个医疗用途，控制（驱动）医疗器械硬件或运行于专用（医用）计算平台。
软件版本号规范与命名原则
软件版本号规范与命名原则1. 软件版本阶段说明* Alpha版: 此版本表⽰该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，⼀般⽽⾔，该版本软件的Bug较多，需要继续修改。
* Beta版: 该版本相对于α版已有了很⼤的改进，消除了严重的错误，但还是存在着⼀些缺陷，需要经过多次测试来进⼀步消除，此版本主要的修改对像是软件的UI。
* RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发⾏的正式版相差⽆⼏。
* Release版: 该版本意味“最终版本”，在前⾯版本的⼀系列测试版之后，终归会有⼀个正式版本，是最终交付⽤户使⽤的⼀个版本。
该版本有时也称为标准版。
⼀般情况下，Release不会以单词形式出现在软件封⾯上，取⽽代之的是符号(R)。
2. 版本命名规范软件版本号由四部分组成：第⼀个1为主版本号第⼆个1为⼦版本号第三个1为阶段版本号第四部分为⽇期版本号加希腊字母版本号希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
例如：1.1.1.051021_beta常规：完全的版本号定义，分三项：：<主版本号>.<次版本号>.<修订版本号>，如 1.0.03. 版本号定修改规则* 主版本号(1)：当功能模块有较⼤的变动，⽐如增加多个模块或者整体架构发⽣变化。
此版本号由项⽬决定是否修改。
* ⼦版本号(1)：当功能有⼀定的增加或变化，⽐如增加了对权限控制、增加⾃定义视图等功能。
此版本号由项⽬决定是否修改。
* 阶段版本号(1)：⼀般是 Bug 修复或是⼀些⼩的变动，要经常发布修订版，时间间隔不限，修复⼀个严重的bug即可发布⼀个修订版。
此版本号由项⽬经理决定是否修改。
* ⽇期版本号(051021):⽤于记录修改项⽬的当前⽇期，每天对项⽬的修改都需要更改⽇期版本号。
此版本号由开发⼈员决定是否修改。
* 希腊字母版本号(beta):此版本号⽤于标注当前版本的软件处于哪个开发阶段，当软件进⼊到另⼀个阶段时需要修改此版本号。
软件版本号命名规范
1. 1.版本命名规范软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release2. 2.软件版本阶段说明Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。
测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。
Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。
修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。
RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。
Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。
该版本有时也称标准版。
3. 3.版本号修改规则（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。
此版本号由项目决定是否修改。
（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。
此版本号由项目决定是否修改。
（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
软件版本命名规范
1. 软件版本阶段说明* Base 版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
* Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开辟者内部交流，普通而言，该版本软件的 Bug 较多，需要继续修改。
* Beta 版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的 UI。
* RC 版: 该版本已经相当成熟了，基本上不存在导致错误的 BUG ，与即将发行的正式版相差无几。
* Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。
普通情况下，Release 不会以单词形式浮现在软件封面上，取而代之的是符号(R)。
软件版本号由四部份组成，第一个 1 为主版本号，第二个 1 为子版本号，第三个 1 为阶段版本号，第四部份为日期版本号加希腊字母版本号，希腊字母版本号共有 5 种，分别为：base、alpha、beta、 RC、 release。
例如： 1.1.1.051021_beta。
* 主版本号(1) ：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
* 子版本号(1) ：当功能有一定的增加或者变化，比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
* 阶段版本号(1) ：普通是 Bug 修复或者是一些小的变动，要时常发布修订版，时间间隔不限，修复一个严重的 bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
* 日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
此版本号由开辟人员决定是否修改。
软件项目版本号的命名规则及格式
软件项⽬版本号的命名规则及格式版本控制⽐较普遍的 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 ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。
软件产品版本号命名规范
软件产品版本号命名规范软件产品版本号命名规范1、⽬的规范软件产品版本号，避免软件测试、发布时软件各模块版本不兼容问题。
2、范围C3M平台软件及绿⾊⾏动管理平台。
3、命名规范软件产品版本号命名规范参考 .Net Framework风格的版本号命名格式，以：主版本号.次版本号.内部版本号.修订号四位表⽰。
软件初版时，版本号为：1.0.0.0。
主版本号：标识软件架构、设计思想，主版本号不同的程序集不可互换，即使具有相同名称也不可互换。
软件架构、设计思想改变或⼤量重写，主版本号加1。
主版本号改变，不⽀持向后兼容性，次版本号、内部版本号及修订号复位为0。
次版本号：当在原有基础上增加了部分功能，涉及数据库的改动，次版本号加1，内部版本号及修订号复位为0。
内部版本号：当软件各模块间接⼝变更时，内部版本号加1，修订号复位为0。
只要有某个或某⼏个模块的接⼝发⽣变动，所有模块的内部版本号统⼀增加1。
修订号：名称、主版本号、次版本号、内部版本号都相同，但修订号不相同的程序集可以完全互换。
以软件编译⽇期（⽉⽇）4位数字作为修订号，如10⽉5号，则为1005。
当天发布的多次软件，⽤后编译的软件程序完全替换前边编译的软件程序。
主版本号、次版号及内部版本号，其中任何⼀个如果需要变更，需要向软件负责⼈申请，由软件负责⼈确定。
软件负责⼈将统⼀修改软件产品版本号，并通知所有相关开发⼈员。
开发⼈员每次的改动必须写开发⽇志，注明改动了哪些东西，修正了哪些BUG，是否对其它模块有影响，是否对数据库有改动。
软件产品所需要的主版本号、次版本号、内部版本号，出现任何⼀个变更，软件产品需要整体升级。
4、软件模块版本号软件各模块需要独⽴的主版本号、次版本号、内部版本号，其中对公共模块或公共组件的版本号，为完全独⽴的版本号，与软件产品版本号的主版本号，次版本号，内部版本号⽆关。
对业务模块的版本号，其主版本号与软件产品的版本号⼀致，次版本号，内部版本号为独⽴版本号。
程序版本号命名规则
程序版本号命名规则程序版本号命名规则是指为软件或应用程序的不同版本，进行统一的命名标准和规则。
正确的版本号命名规则可以提高软件的管理和维护效率，方便用户理解和使用。
下面是一些常见的程序版本号命名规则的参考内容：1. 主版本号-次版本号-修订号-编译号这是一种常见的版本号命名规则。
主版本号表示软件的大版本更新，通常意味着有重大的功能改动或架构调整；次版本号表示较大范围的功能增强或改进；修订号表示小范围的 bug 修复或性能优化；编译号一般用于在修复一些紧急问题时进行的小版本发布。
2. 年份.月份以年份和月份作为版本号的命名规则，适用于一些长期维护的软件。
每个月的版本更新会以当月的年份和月份作为版本号的标识，方便用户明确知道该版本是在哪个时间段发布的。
3. X.Y.Z这是一种常见的简洁的版本号命名规则。
其中，X 表示主要版本号，通常表示的是有重大改进或新功能的版本更新；Y 表示次要版本号，通常表示一些较小的功能改进或 bug 修复；Z表示修订版本号，通常表示的是一些小的 bug 修复或性能优化。
4. 语义化版本号语义化版本号是一种使用数字和点号进行命名的规则，具有标准的格式和含义。
例如，1.0.0 表示第一个正式版发布；1.0.1 表示在第一个正式版的基础上进行了紧急的修复；1.1.0表示在第一个正式版的基础上增加了新功能，无兼容性问题；2.0.0 表示有重大的、不兼容的改动等。
这种版本号命名规则提供了更多的信息，方便用户判断版本之间的兼容性和重要性。
5. 固定迭代周期有些软件团队会采用固定迭代周期来进行版本发布，例如每个季度或每半年发布一个大版本，每个月发布一个小版本。
这样的命名规则可以帮助用户明确知道该版本是在什么时候发布的，以及了解版本号代表的时间范围。
除了上述常见的版本号命名规则，还有一些特定的行业或公司会采用自己的版本号命名规则。
例如，某些开源软件会使用一串日期和散列值来标记版本，以保证版本号的唯一性和可追溯性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件版本命名规则真实性声明
国家药品监督管理局：
xxxxx公司xxx型号的软件版本命名规则如下：
软件版本命名规则为X.Y.Z.B，其中X表示重大增强类更新，影响到产品安全性或有效性，包括跨越互不兼容的操作系统、临床功能改变、软件输出结果改变、用户使用习惯改变、影响到患者安全等软件更新；Y表示轻微增强类更新，不影响医疗器械安全性和有效性，包括为优化算法、提升软件性能及增强非临床功能等软件更新；Z表示纠正类更新，为修正软件缺陷而进行的软件更新，包含已知缺陷的更新、潜在未知缺陷的更新；B表示构建类更新，软件编译生成一个工作版本，是属于纠正类更新。
软件完整版本为X.Y.Z.B，软件发布版本为X。
以上内容均真实、合法。
如有不实之处，我单位愿承担相应的法律责任，并承担由此产生的一切后果。
特此声明！
XXXXXX公司
20XX年XX月XX日
—1 —。