项目软件版本管理方式
- 格式:docx
- 大小:58.31 KB
- 文档页数:7
软件版本管理规范软件版本管理是软件开发过程中非常重要的一环,它对于保证软件的稳定性、可靠性和持续改进至关重要。
本文将介绍软件版本管理的规范,并提供一些最佳实践方法。
1. 版本管理概述软件版本管理是指对软件开发过程中产生的各个版本进行有效的记录、追踪和控制的过程。
通过版本管理,开发人员可以更好地管理和控制软件的迭代过程,快速回溯和解决问题,并进行版本发布和部署。
2. 版本控制系统选择为了进行有效的软件版本管理,选择合适的版本控制系统是至关重要的。
目前,常用的版本控制系统包括Git、SVN等。
在选择版本控制系统时,应考虑团队规模、项目需求、安全性和易用性等因素。
3. 分支管理策略分支是版本管理中的一个重要概念,它可以用来组织和管理不同功能或者不同版本的代码。
在进行分支管理时,应采用适当的策略,例如主分支只用于发布稳定版本,开发人员在从主分支拉取新分支进行开发等。
4. 版本命名规范为了方便追踪和识别版本,应采用一致的版本命名规范。
常用的版本命名规范包括主版本号、次版本号和修订号,例如1.0.0。
在进行版本升级时,应遵循一定规则,例如主版本号的升级表示不兼容的变更,次版本号的升级表示向下兼容的功能性变更,修订号的升级表示修复bug或者进行优化。
5. 版本发布和部署流程版本发布和部署是软件开发中的关键环节之一。
为了确保发布和部署的顺利进行,应建立相应的流程和规范。
例如,在进行版本发布前,应进行相关测试,包括单元测试、集成测试和回归测试等。
发布后,还应做好版本的文档更新、用户通知和性能监控等工作。
6. 版本记录和变更日志为了追踪和记录每个版本的变更情况,应建立完善的版本记录和变更日志。
版本记录可以包括版本号、发布日期、变更内容、责任人等信息,而变更日志则可以详细描述每个版本的新增、修改和删除的功能点。
7. 版本回退和紧急修复在软件开发过程中,可能会出现某个版本存在严重问题的情况,需要进行回退或者紧急修复。
为了应对这种情况,应建立相应的应急处理流程和规范,例如定期备份代码、建立热修复机制等。
软件开发中的版本管理技巧一、版本管理的定义及意义版本管理(Version Control)是指在软件开发过程中,对软件源代码和相关文件进行控制、追踪和管理的一种方法。
它能够记录软件的历史变更信息,帮助开发团队更好地协作工作,保证软件开发的顺利进行。
版本管理在现代软件开发中具有不可替代的重要性。
二、传统版本管理工具1. CVS(Concurrent Versions System)CVS是早期版本管理工具中最受欢迎的一种。
它使用集中式模型,将集中存储库作为代码的唯一副本,并使用锁定机制进行协作开发。
然而,由于其集中式结构带来的单点故障问题和网络传输效率低下等缺点,CVS逐渐被其他更先进的版本管理工具取代。
2. SVN(Subversion)SVN是一种集中式版本管理系统,相对于CVS具有更多的功能和优势。
它支持文件和目录的版本控制、权限控制、分支合并等功能,使得团队协作更加灵活高效。
然而,随着分布式版本管理工具的出现,SVN逐渐被取代。
三、分布式版本管理工具的兴起1. GitGit是一种分布式版本管理系统,由于其分布式结构和高效的存储方式,成为目前最流行的版本管理工具之一。
它允许每个开发者都有完整的版本库副本,并可以离线工作。
Git通过快照式存储和分支管理的灵活性,使得开发团队可以轻松并行工作,更好地管理代码。
2. MercurialMercurial是另一种分布式版本管理系统,与Git类似。
它在易学性和用户友好性上更胜一筹,对于小团队或个人开发者来说是一个不错的选择。
Mercurial提供了强大的分支管理和分布式开发功能,支持大型项目的版本控制。
四、版本管理的技巧1. 分支管理分支是版本管理中非常重要的概念,它能够让开发者在不影响主线开发的情况下进行特性开发、修复bug等工作。
合理使用分支可以降低冲突风险,提高并行开发效率。
主线分支通常用于发布生产版本,开发者可以从主线分支创建自己的特性分支,完成开发后再合并到主线上。
软件项目实施保障措施之配置管理与版本控制一、引言在软件项目的实施过程中,配置管理和版本控制是非常重要的保障措施。
配置管理旨在确保软件开发过程中的配置项的可控性和可追溯性,而版本控制则用于管理软件不同版本之间的变更和迭代。
本文将探讨软件项目实施中的配置管理和版本控制,并提出相应的保障措施。
二、配置管理配置管理是指对软件开发过程中涉及的配置项进行有效的控制和追踪管理的过程。
配置项可以包括源代码、可执行文件、文档等。
配置管理的目标是实现可重复和可控制的软件开发流程,确保软件的正确性和可维护性。
1. 配置项标识每个配置项都应该有一个唯一的标识符,以方便跟踪和管理。
可以使用版本号、日期时间等作为标识符,确保每个配置项都能够进行正确的追溯。
2. 配置项控制对于每个配置项,应制定相应的控制策略,包括配置项的创建、修改和删除等操作。
只有经过授权的人员才能进行相关操作,并且需要进行相应的记录和审查,以确保配置项的安全和可追溯性。
3. 配置项变更管理在软件开发过程中,可能会出现配置项的变更需求。
为了确保变更的有效性和可控性,需要建立一个变更管理机制。
变更管理包括变更申请的提交与审批、变更实施的记录和验证等环节,确保变更的合理性和影响分析。
三、版本控制版本控制是对软件不同版本之间进行管理和控制的过程。
通过版本控制,可以对软件的变更进行追踪和管理,并确保团队成员之间的协同开发效率。
1. 版本控制系统选择根据项目的需求和团队规模,选择适合的版本控制系统。
常用的版本控制系统包括Git、SVN等。
在选择版本控制系统时,需要考虑其功能、易用性和扩展性等方面的因素。
2. 分支管理通过分支管理,可以将软件开发过程中的不同功能点或任务进行隔离。
每个功能点或任务都可以独立创建一个分支,并在该分支上进行开发和测试。
最后通过合并分支的方式将各个功能点或任务整合到主分支中。
3. 变更冲突解决在多人协同开发的过程中,可能会出现多个人同时修改同一个文件或代码块的情况,导致冲突。
项目版本管理规范一、背景介绍项目版本管理是指在软件开辟过程中,对项目代码和文档进行有效管理和控制,以确保团队成员之间的协作顺畅,并保证项目的稳定性和可靠性。
本文将介绍项目版本管理的标准格式和相关要求。
二、版本管理工具1. Git:Git是目前最流行的分布式版本控制系统,具有强大的分支管理和合并能力,适合于团队协作开辟。
2. SVN:SVN是集中式版本控制系统,适合于小型项目或者个人开辟。
三、版本管理流程1. 创建仓库:在版本管理工具中创建项目仓库,并设置相应的权限和分支策略。
2. 分支管理:根据项目需求,创建主分支(Master)和开辟分支(Develop),团队成员在开辟分支上进行开辟。
3. 版本发布:当开辟分支上的功能开辟完成并经过测试验证无误后,将其合并到主分支,并打上版本号进行发布。
4. 缺陷修复:如果在发布后发现了缺陷,可以在主分支上创建暂时分支进行修复,修复完成后合并到主分支,并打上修订版本号。
5. 版本回退:如果某个版本浮现了严重问题,可以通过版本回退的方式将代码还原到之前的稳定版本。
四、版本号规范版本号通常采用主版本号.次版本号.修订版本号的格式,例如1.0.0。
具体规范如下:1. 主版本号:当项目进行了重大的功能改变或者架构调整,且不兼容之前的版本时,主版本号加1。
2. 次版本号:当项目新增了功能或者进行了较大的优化,且兼容之前的版本时,次版本号加1。
3. 修订版本号:当项目进行了缺陷修复或者进行了小的改进,且兼容之前的版本时,修订版本号加1。
4. 预发布版本号:当项目处于开辟阶段,但已经具备部份功能时,可以在版本号后加之预发布标识,如1.0.0-alpha、1.0.0-beta等。
五、提交规范1. 提交信息:每次提交待码时,需要提供清晰明确的提交信息,包括修改的文件、修改的内容和修改的原因。
2. 提交频率:建议频繁提交待码,每一个提交尽量只包含一个功能或者一个缺陷修复,避免多个功能或者修复混合在一个提交中。
广东亿迅科技有限公司软件版本管理办法(暂行)第一章总则第一条为了加强广东亿迅科技有限公司(以下简称“公司”)的软件版本管理工作,进一步细化公司配置管理规范,建立软件版本管理的规范化操作流程,保证公司软件产品质量,制定本办法。
第二条本办法适用于公司各技术部门的软件版本管理工作。
第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。
第四条软件版本(以下简称“版本”)管理应遵循以下原则:(一)实施版本变更应符合以下原则之一:1.为满足客户新业务、新功能需求;2.为满足提高业务质量、提升业务性能指标和容量扩充的需求;3.为解决软件故障和软件稳定性、安全性、可控性问题;4.为了提高软件可维护性。
(二)版本的集成和发布应严格按照计划执行,避免随意和频繁更新版本;(三)为保证软件质量,任何一个软件版本须通过版本测试后方可上线;(四)公司所有软件版本必须通过正式渠道发布给用户,未经审批各部门和个人不得擅自向用户发布软件版本。
第五条版本管理是保障应用软件正常运行的一个重要手段,各相关部门应认真贯彻落实,并纳入工作考核;未按本办法执行从而造成版本故障影响用户正常生产的,一经发现将追究其相应责任。
第二章职责与分工第六条版本管理实行总体质量控制,分级实施管理原则,管理工作涉及版本质量管控部门和版本集成发布部门;质量管理部是版本质量管控部门,各业务部门是版本集成发布部门。
第七条版本质量管控部门的工作职责如下:(一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实;(二)负责组织版本管理相关的培训并提供技术支持;(三)负责跟踪和监督公司版本管理工作的执行情况,协调解决执行中的问题,并对版本管理的执行效果进行评估考核;(四)负责组织和实施对版本的测试验证工作;(五)负责对版本升级实施效果和版本质量进行监控和评估;(六)其它应由版本质量管控部门负责的事项。
第八条版本集成发布部门的工作职责如下:(一)负责本部门版本研发集成工作环境的建立、维护和管理;(二)负责依据版本管理工作流程,执行版本开发、集成、发布及维护的相关工作;(三)负责收集分析业务需求,制定版本计划并按计划组织实施;(四)负责跟踪版本上线后的运行情况,收集用户使用的反馈信息,改进版本质量;(五)其它应由版本集成发布部门负责的事项。
项目版本管理规范一、引言项目版本管理是一种重要的软件开发管理方法,旨在确保项目代码的可追溯性、可复用性和可维护性。
本文档旨在规范项目版本管理的流程和规则,以确保项目的顺利进行。
二、背景版本管理是指对软件开发过程中产生的各个版本进行管理和控制的过程。
通过版本管理,可以跟踪和记录项目代码的变更历史,方便团队成员之间的协作,同时也能够追溯和还原特定版本的代码。
三、版本管理流程1. 分支管理项目开发过程中,通常会有多个分支,如主分支、开发分支、测试分支等。
每个分支都有其特定的用途和权限。
以下是常见的分支管理策略:- 主分支(master):用于发布稳定版本的代码,只能由经过严格测试的代码合并而成。
- 开发分支(develop):用于开发新功能和修复bug,所有开发人员都可以在该分支上进行开发。
- 功能分支(feature):用于开发单个功能模块,从开发分支上拉取,开发完成后合并回开发分支。
- 测试分支(test):用于测试团队进行测试,从开发分支上拉取,测试完成后合并回开发分支。
2. 版本命名规范版本命名是版本管理中的重要环节,可以根据实际情况进行命名,常见的命名规范如下:- 主版本号(Major Version):当项目有重大变更或突破性的功能更新时,增加主版本号。
- 次版本号(Minor Version):当项目有新增功能或较大的bug修复时,增加次版本号。
- 修订版本号(Patch Version):当项目有小的bug修复或优化时,增加修订版本号。
- 预发布版本号(Pre-release Version):在正式发布之前,可以使用预发布版本号进行内部测试。
- 构建版本号(Build Version):每次构建时自动生成的唯一标识,用于区分不同的构建版本。
3. 变更管理项目开发过程中,难免会出现代码变更的情况。
为了保证变更的可控性和可追溯性,需要遵循以下变更管理规则:- 所有的变更都需要通过版本控制系统进行管理,禁止直接修改线上代码。
项目版本管理规范一、背景和目的项目版本管理是指对软件项目开发过程中的不同版本进行有效管理和控制的一种方法。
通过版本管理,可以确保团队成员之间的协作顺畅,减少冲突和错误,并提高项目开发的效率和质量。
本文旨在制定项目版本管理规范,以确保项目开发过程中的版本管理工作得以规范和有效进行。
二、适用范围本规范适用于项目开发过程中的版本管理工作,包括但不限于软件开发项目、网站开发项目等。
三、术语定义1. 版本:指软件或项目的不同发布或修改状态。
2. 主版本号:用于标识软件或项目的重大改动或功能增加。
3. 次版本号:用于标识软件或项目的小幅改动或功能优化。
4. 修订号:用于标识软件或项目的错误修复或细微调整。
5. 版本控制系统:用于管理和控制软件或项目版本的工具或系统,如Git、SVN等。
四、版本号命名规则1. 版本号由三部分组成:主版本号.次版本号.修订号。
2. 主版本号、次版本号、修订号均为非负整数。
3. 当进行重大改动或功能增加时,主版本号加1,次版本号和修订号归零。
4. 当进行小幅改动或功能优化时,次版本号加1,修订号归零。
5. 当进行错误修复或细微调整时,修订号加1。
五、版本管理流程1. 创建版本库:在版本控制系统中创建项目的版本库,并设置合适的权限控制。
2. 初始化版本库:将项目的初始代码或文件导入版本库,并进行首次提交。
3. 分支管理:根据项目需要,创建主分支和开发分支。
主分支用于发布稳定版本,开发分支用于进行功能开发和测试。
4. 版本提交:开发人员根据任务分配和进度,将代码或文件提交到相应的分支中。
5. 版本合并:当开发分支的功能开发和测试完成后,将开发分支合并到主分支中,并进行测试和验证。
6. 版本发布:经过测试和验证的版本,由项目负责人或项目经理决定发布到生产环境或客户端。
7. 版本回滚:如果发布的版本出现问题或不符合需求,需要及时进行版本回滚,恢复到之前的稳定版本。
8. 版本记录:在版本控制系统中记录每个版本的变更内容和日期,以便追溯和管理。
项目版本管理规范引言概述:项目版本管理是软件开辟过程中的重要环节,它能够匡助团队有效地管理和控制项目的版本,确保项目的稳定性和可追溯性。
本文将介绍项目版本管理的规范,包括版本命名规则、分支管理、变更记录、发布流程和文档管理。
一、版本命名规则:1.1 版本号命名规则:版本号普通由主版本号、次版本号和修订号组成,格式为“主版本号.次版本号.修订号”。
主版本号表示重大功能更新或者架构调整,次版本号表示新增功能或者较大的改进,修订号表示Bug修复或者小的改动。
1.2 预发布版本命名规则:预发布版本可以使用“alpha”、“beta”、“rc”等标识,表示开辟阶段、测试阶段和发布候选阶段。
1.3 版本标签命名规则:版本标签可以使用日期、里程碑、功能名称等进行命名,便于团队成员快速定位和识别不同的版本。
二、分支管理:2.1 主分支管理:主分支普通用于发布稳定版本,团队成员不能直接向主分支提交待码,只能通过合并其他分支或者发起合并请求来更新主分支。
2.2 开辟分支管理:开辟分支用于团队成员进行日常开辟工作,每一个团队成员在自己的开辟分支上进行开辟,并定期将开辟分支合并到主分支。
2.3 暂时分支管理:暂时分支用于解决紧急Bug修复或者特定功能开辟,修复完毕或者功能开辟完成后,应及时合并到开辟分支或者主分支。
三、变更记录:3.1 提交信息规范:每次代码提交都应包含故意义的提交信息,清晰地描述代码变更的内容和目的,方便团队成员和未来的维护人员了解代码的变更历史。
3.2 变更日志维护:团队应该定期维护变更日志,记录每一个版本的功能变更、Bug修复和性能优化等内容,方便项目管理和版本追溯。
3.3 版本比对和回滚:在浮现问题或者需要回滚到之前的版本时,团队应及时进行版本比对,找出问题所在,并进行相应的修复或者回滚操作,确保项目的稳定性。
四、发布流程:4.1 发布计划制定:在发布新版本之前,团队应制定详细的发布计划,包括版本号、发布日期、发布内容和测试计划等,确保发布过程有序进行。
如何进行软件产品的版本管理在如今的软件开发领域中,版本管理已经成为了非常必要的一项工作。
一个良好的版本管理方案可以帮助团队成员协同工作、掌握开发进度以及快速恢复历史版本,同时也可以提高团队的工作效率和协作效果。
那么,如何进行软件产品的版本管理呢?以下是一些方法和建议。
1. 使用版本控制工具版本控制工具是进行版本管理的必备工具。
这类工具可以帮助我们管理源代码、文档、配置文件等项目文件,并跟踪这些文件的版本、变化和历史记录。
常见的版本控制工具包括Git、SVN、Mercurial等。
其中,Git是最受欢迎的开源版本控制工具,它具有分布式版本控制的特点,可以轻松地处理并发开发、分支合并等情况。
在使用版本控制工具时,我们需要遵循一些基本的使用规则。
首先,每个团队成员都应该具有独立的账号和权限,以便进行版本控制和协同工作。
其次,每个开发分支应该有一个唯一的分支名称,并尽量保证分支之间的独立性,避免对彼此造成影响。
最后,我们需要定期提交代码,并及时跟进团队成员之间的合并请求和代码审查。
2. 采用语义化版本号语义化版本号是指根据软件版本的含义和语义来递增版本号。
常见的格式为X.Y.Z,其中X表示主版本号,Y表示次版本号,Z表示修订号。
例如,1.2.3版本号中,1为主版本号,2为次版本号,3为修订号。
在使用语义化版本号时,我们需要遵循一些规则,例如只有修订号可以递增、次版本号递增表示向后兼容、主版本号递增表示不向后兼容等。
采用语义化版本号可以更好地理解软件版本的含义和演变,方便进行版本迭代和升级。
3. 定期发布新版本软件开发是一个不断优化和迭代的过程,每个新版本都会带来一些改进和修复。
定期发布新版本是进行版本管理的重要步骤之一。
在发布新版本时,我们需要从当前分支中选择合适的版本进行打包、测试和发布。
同时,我们需要及时通知用户和开发者新版本的变化和升级方式,保证用户和开发者可以顺利使用和扩展。
4. 创建版本发布计划版本发布计划是指按照一定的时间和进度,规划版本的发布和迭代。
项目版本管理规范一、背景和目的在软件开辟过程中,版本管理是一项重要的工作,它能够确保团队成员之间的协作顺利进行,同时也能够保证软件的稳定性和可追溯性。
本文旨在制定一套项目版本管理规范,以确保项目的顺利进行和版本的可控性。
二、适合范围本规范适合于所有项目的版本管理工作,包括但不限于软件开辟项目、网站建设项目等。
三、规范内容1. 版本号命名规范1.1 版本号由主版本号、次版本号和修订号组成,格式为x.y.z,其中x、y、z 为非负整数。
1.2 主版本号(x):当项目进行了重大变更或者增加了重要功能时,主版本号加1。
1.3 次版本号(y):当项目进行了一些较小的功能变更或者增加了一些新功能时,次版本号加1。
1.4 修订号(z):当项目进行了一些bug修复或者进行了一些细微的调整时,修订号加1。
2. 版本控制工具2.1 推荐使用Git作为版本控制工具,通过Git可以对项目进行版本管理、团队协作和代码审查等操作。
2.2 所有项目成员都应熟练掌握Git的基本操作和常用命令,并按照规范进行代码提交和分支管理。
3. 分支管理3.1 主分支3.1.1 主分支(master)用于存放稳定的、可部署的版本,惟独经过测试和审核的代码才干合并到主分支。
3.1.2 主分支上的代码应该是可随时发布的版本,不允许直接在主分支上进行开辟和修改。
3.2 开辟分支3.2.1 开辟分支(develop)用于日常开辟工作,所有开辟人员都应该基于develop分支进行开辟。
3.2.2 每一个开辟人员应该在本地创建自己的开辟分支,并及时将代码推送到远程仓库。
3.3 功能分支3.3.1 功能分支(feature)用于开辟新功能或者进行较大的功能变更,每一个功能分支应该基于develop分支创建。
3.3.2 功能分支开辟完成后,应该及时合并到develop分支,并删除对应的功能分支。
3.4 修复分支3.4.1 修复分支(hotfix)用于紧急修复线上版本的bug,每一个修复分支应该基于主分支创建。
项目软件管理规范
版本号:A
编制日期
审核日期
批准日期
瑞德医疗内部资料,注意保密
历史修改记录
一.
二. 目的
1.1
1.2软件版本按照一定的规则保存所有版本,避免发生版本丢失或混淆等现象,
并且可以快速准确的查找到任何版本。
1.3软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一
管理。
1.4本文档是为规范安徽瑞德医疗器械制造有限公司研发部软件版本管理而制
定的。
三.
四. 范围
2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容,包括:2.2版本标识方法及管理
2.3
2.4版本升级
2.5
2.6文档及源码的备份制度
2.7所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使
用按照文档及源码存放备份制度。
五.
六. 版本管理
3.1
3.2版本号规则
3.1.1
3.1.2每一个归档版本都有两个版本号:内部版本号和外部版本号。
版本号使
用VBP规则,V是指外部版本号(研发测试版本),B是指内部版本号(受控版本),P是指补丁版本号(可选)。
3.1.3
3.1.4版本号命名:项目名称+发布版本(对内/对外)+版本更新记录
3.3版本控制记录
3.2.1版本状态变迁要遵守一定的规则,内部先生成一个内部版本,提交测试
审批,通过了则由开发人员进行版本归档受控,生成外部版本。
(测试人员在测试过程中根据《软件测试规程》检测生成《软件测试报告》再由项目组内部讨论是否能生成新的版本)不通过则为无效版本,需要软件开发人员再进行修改,直至通过。
通过后生成表格记录,再和源码一起打包受控形成外部版本。
3.2.2版本审核记录表如下:每次审核记录添加,审核通过后作为开发文档一
起打包受控。
3.4版本更新记录
3.3.1版本更新软件工程师根据项目内容的变更,优化软件功能的,需要变更
内部版本号提交测试审批,通过了则由开发人员进行版本归档,(测试人员在测试过程中根据项目软件变更优化的内容,结合项目软件整体结合进行测试。
测试完成根据《测试报告》由项目组内部讨论是否能生成新的版本。
不
通过则为无效版本,由开发人员再进行优化工作。
更新记录过程中生成表格记录,审核通过后和源码一起打包受控形成外部版本。
3.5版本受控说明:
3.4.1开发人员完成所负责模块的代码编写任务后,提交到项目经理处
3.4.2项目经理向测试人员提交测试任务
3.4.3测试人员准备测试所需的环境
3.4.4测试人员开展测试并根据《软件测试报告》实时提交BUG
3.4.5开发人员处理测试过程中所出现的BUG,并提交给测试人员进行回归测
试,直至BUG被解决
3.4.6测试基本完成后,测试人员提交测试报告
3.4.7根据项目市场需求结合实际情况决定是否发布新的版本
3.4.8测试人员与各相关人员经讨论后确定好新版本各项信息
3.4.9测试人员发布新版本
3.6如何体现产品版本号
3.5.1上位机体现变更版本号:上位机可以发送查看下位机版本号命令字给下
位机,下位机通过发送反馈命令字来体现当前版本号。
上位机可直接查看当前版本号。
(设备拥有上位机条件下可使用,液晶显示也可使用)
3.5.2无上位机反馈变更版本号:如果没有上位机显示的条件下,可以通过在
电路板上做对应版本号的标识来区分,通过查看电路板上的标识确认下位机软件版本号。
七. 版本升级
4.1版本升级原则
4.1.1版本升级应严格纳入版本管理的控制之下。
应当谨慎地控制版本的升级,
保障高版本下的兼容性,提供严格定义的升级方法。
4.1.2在下面几种情况下,进行版本演化和升级:
1)当产品发生重大修改和改进时,主版本号加1。
2)重大修改和改进包括:a平台迁移;b开发工具的迁移;c体系结构的变迁。
4.1.3记录版本升级过程。
每次版本升级,都要填写版本升级记录表,记录表
样例如下:(仅供外部版本升级)内部版本和修订版本分别使用版本审核记录表、版本更新记录表。
4.2新版本的发布
4.2.1新版本的发布指对外新版本程序的升级,内部版本程序和变更版本程序
只对研发部内部升级。
流程如下:
1)根据项目进展情况,或者根据用户需要、市场需求进行发布准备。
2)将发布所需文件进行打包整理,放在指定目录中,给目录加上标签,标
签中包含将要发布的版本信息。
对外部门发布只发布供程序烧写的HEX
文件。
3)同样对源码文件也要加上与版本信息相关的标签。
八. 文档及源码存放备份制度
5.1开发文档
5.1.1各项目的开发文档根据对外新版本程序的发布做出相对应的变更,内部
版本程序和更新的程序不做变更。
5.1.2根据各项目组自己的情况,将市场需求记录、总体设计文档、详细设计
及数据结构文件、测试记录、用户手册等放入备份文件中与源代码一起打包保存。
5.2源代码的存放
5.2.1源代码包括如:上位机、下位机相关文件,是未经编译处理的、不能直
接交付使用的产品文件(测试阶段文件)以及编译产品所需的文件,包括可以直接烧写的HEX文件。
由研发部保管。
5.2.2源代码的借阅、复制必须进行详细的登记,必需记录借阅人、批准人、
借阅时间、借阅目的、文件流向、文件版本或内容、归还时间(登记记录由研发部存档)。
5.2.3源代码向软件部门以外复制必须获得部门经理的授权。
并必需记录复制
人、批准人、复制时间、复制目的、文件流向、文件版本或内容。
5.2.4对于因合作需要,需要向外复制、传播、分发源代码的,不论是全部还
是部分代码和资料,均必需和对方签订技术、源码的保密协定,明确对方应当承担的对源码保密的责任和义务。
(没有必要只需要交付HEX文件,禁止源代码传播)
5.2.5受控文件要备份好版本,并发送给项目负责人及研发部经理,备份过程
中添加到压缩文件要加密,密码可以统一为公司常用密码,防止外部人员盗用。