Atitit.研发管理---api版本号策略与版本控制

Atitit.研发管理---api版本号策略与版本控制

1. 1.2.1版本概述1

2. 3主版本号策略2

3. 1PATCH版本策略2

3.1. 1.2.2.1次版本号策略2

表3-1 APR中支持的基本类型

每一个APR的实现我们都在后面会详细描述。

1. 1.2.1版本概述

APR中使用三个整数来记录APR版本号：MAJOR.MINOR.PATCH。MAJOR表示当前APR的主版本号，它的变化通常意味着APR的巨大的变化，比如体系结构的重新设计，API的重新设计等等，而且这种变化通常会导致APR版本的向前不兼容。MINOR称之为APR的次版本号，它通常只反映了一些较大的更改，比如APR的API的增加等等，但是这些更改并不影响与旧版本源代码和二进制代码之间的兼容性。PATCH通常称之为补丁版本，通常情况下如果只是对APR函数的修改而不影响API接口的话都会导致PATCH的变化。

作者:: 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ） 汉字名：艾龙，  EMAIL:1466519819@qq.com

转载请注明来源： http://blog.csdn.net/attilax

2. 3主版本号策略

下面的任何一种变化都将可能导致主版本号的变化：

1)、常量的移除或者更改

2)、函数移除或者作为

3)、fold together macro-ized function replacements

3. 1PATCH版本策略

在前表中我们看到，PATCH的变化并不影响版本的源代码和二进制级别的兼容性，包括向前和向后兼容，因此，我们很容易看出，PATCH版本变化通常意味着对版本的修修补补，即BUG的修复。这些工作通常被局限于函数内部的修改，或者是API函数内部，或者是APR内部static函数的变化。任何对API的增加、修改、删除都是不允许的。

3.1. 1.2.2.1次版本号策略

任何新函数，新变量以及新常量的引入以及任何现有函数的废除都将可能导致次版本号的变化：

、函数作废

随着APR的升级，APR中的一些API可能将作废，不再使用，但是这些API并不能从APR库中移除。因为一旦API被移除，向后兼容性将被破坏。因此我们能够做的仅仅是宣布其作废。