软件版本命名规则真实性声明

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）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。

医疗器械软件注册技术审查指导原则本指导原则旨在指导制造商提交医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求。

本指导原则是对医疗器械软件的一般性要求，制造商应根据医疗器械软件的特性提交注册申报资料，判断指导原则中的具体内容是否适用，不适用内容详述理由。

制造商也可采用其他满足法规要求的替代方法，但应提供详尽的研究资料和验证资料。

本指导原则是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技术报告制定的。

随着法规和标准的不断完善，以及认知水平和技术能力的不断提高，相关内容也将适时进行修订。

本指导原则是对制造商和审查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在遵循相关法规的前提下使用本指导原则。

本指导原则针对软件的特殊性，在现行法规要求下进一步明确了对医疗器械软件的要求，特别是对软件更新、软件版本的要求。

本指导原则是医疗器械软件的通用指导原则，其他涉及软件医疗器械产品的指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。

一、范围本指导原则适用于医疗器械软件的注册申报，包括第二类、第三类医疗器械产品，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。

医疗器械软件包括独立软件和软件组件。

独立软件：作为医疗器械或其附件的软件；软件组件：作为医疗器械或其部件、附件组成的软件。

独立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台。

独立软件包括通用型软件和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如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、范围C3M平台软件及绿色行动管理平台。

3、命名规范软件产品版本号命名规范参考 .Net Framework风格的版本号命名格式，以：主版本号.次版本号.内部版本号.修订号四位表示。

软件初版时，版本号为：1.0.0.0。

主版本号：标识软件架构、设计思想，主版本号不同的程序集不可互换，即使具有相同名称也不可互换。

软件架构、设计思想改变或大量重写，主版本号加1。

主版本号改变，不支持向后兼容性，次版本号、内部版本号及修订号复位为0。

次版本号：当在原有基础上增加了部分功能，涉及数据库的改动，次版本号加1，内部版本号及修订号复位为0。

内部版本号：当软件各模块间接口变更时，内部版本号加1，修订号复位为0。

只要有某个或某几个模块的接口发生变动，所有模块的内部版本号统一增加1。

修订号：名称、主版本号、次版本号、内部版本号都相同，但修订号不相同的程序集可以完全互换。

以软件编译日期（月日）4位数字作为修订号，如10月5号，则为1005。

当天发布的多次软件，用后编译的软件程序完全替换前边编译的软件程序。

主版本号、次版号及内部版本号，其中任何一个如果需要变更，需要向软件负责人申请，由软件负责人确定。

软件负责人将统一修改软件产品版本号，并通知所有相关开发人员。

开发人员每次的改动必须写开发日志，注明改动了哪些东西，修正了哪些BUG，是否对其它模块有影响，是否对数据库有改动。

软件产品所需要的主版本号、次版本号、内部版本号，出现任何一个变更，软件产品需要整体升级。

4、软件模块版本号软件各模块需要独立的主版本号、次版本号、内部版本号，其中对公共模块或公共组件的版本号，为完全独立的版本号，与软件产品版本号的主版本号，次版本号，内部版本号无关。

对业务模块的版本号，其主版本号与软件产品的版本号一致，次版本号，内部版本号为独立版本号。

但要求与软件产品的版本号的编码格式一致。

软件命名及管理规范目的：为了公司内部软件版本管理的规范性，为了量产软件编写记录的规范及可追述性，为了量产资料的完整性、准确性。

一、命名要求：1．如果客人没有明确要求情况下，芯阳公司自行开发的软件命名规则为：客户名（ES）、产品名（292）、类别（可不体现）、特征（可不体现）、版本（V1.0）1.1 上述各个命名之间不要增加任何符号。

“ES292V1.0”1.2 首版命名为V1.0，第二版命名为V1.1（.1~.9）。

如果有重大修改如PCB完全变化的话命名为V2.0，以此类推。

1.3 如果预知共用UL、GS规格基板或预知计时时间不同等情况下软件命名增加类别或特征说明。

如：“ETA-17DUL15minV1.0”和“ETA-17DUL60minV1.0”做区分。

1.4 如果客人有要求自己的命名规则按照客人命名要求。

二、管理规范：1. 开发过程的管理规范：1.1 软件编写时以主程序调用子程序的方式编写，主程序和子程序分别建立独立的.asm或.dt文件，且同时在一个文件夹下。

1.2 文件夹命名以时间排序。

1.3 要求文件夹旁边单独建立一个word档文件和一个OLD文件夹。

将更改过程的软件转存至此OLD文件夹下，当前目录下只会保留最终版本的软件和OLD文件夹，避免过多版本参杂；word档文件用于记录软件变更历史信息。

原则上所有调试过程中的版本的软件都不要删除，保留可追述性。

内容如下：2. 量产程序管理规范：2.1 量产程序将最终烧录档和打包好的源程序放置于服务器的“最终量产程序汇总”文件夹下对应的机种的目录下。

2.2 在此文件夹树形文件依次为：客户——机种——规格——烧录档+说明.txt+照片+打包好的源程序。

2.3 因为很多机种都会有不同的规格所对应的程序，所以为方便查找机种上先不区分规格，在该机种的文件夹内部再区分规格。

2.4 烧录档旁边需要放置一个说明文件，说明此烧录档所适用的机种，烧写编译的IC型号，封装，烧写前、后的Checksum，更新的时间，更新人。