1、MAJOR
- MAJOR表示当前APR的主版本号，它的变化通常意味着APR的巨大的变化，比如体系结构的重新设计，API的重新设计等等，而且这种变化通常会导致APR版本的向前不兼容。
2、MINOR - MINOR称之为APR的次版本号，它通常只反映了一些较大的更改，比如APR的API的增加等等，但是这些更改并不影响与旧版本源代码和二进制代码之间的兼容性。
3、PATCH - PATCH通常称之为补丁版本，通常情况下如果只是对APR函数的修改而不影响API接口的话都会导致PATCH的变化。目前为止APR的最高版本是1.2.2，最早遵循这种规则的版本号是0.9.0，不过在0.9.0之前，APR还推出了两个版本a8和a9。
不过有一点需要注意的是，我们后面描述的版本规则并不适合1.0.0以前的版本。对于1.0.0以前的版本(0.x.y)，APR提供的API是可以任意的改变而没有任何的限制，因此这些版本的变化不遵循后面描述的版本规则。从1.0.0以后的所有版本都遵循。切记。除非主版本号发生变化，否则如果某个应用程序使用了低版本的APR，那么如果将该版本用高版本的APR替代，应用程序必须能够无错误的编译通过，通常我们称之为前向兼容行；反之很明显，如果应用程序中使用了高版本的APR，那么如果将该版本用低版本的APR替代，则未必能够编译通过，通常我们称之为后向不兼容。APR的发展中力图总是保持与旧版本的源代码和二进制版本之间的兼容性。通过源代码兼容，应用程序就可以在使用新版本的APR进行编译的时候不会报错，这样应用程序就不需要为了适应新的APR而做出调整，从而保持应用开发的一致性和持续性。除非APR的主版本号发生变更。这种兼容性反之则不成立。如果一个应用程序使用较高的MINOR版本开发，那么很明显，如果将该版本替换为MINOR相对较低的版本进行编译，则成功的可能性应该不是很大。除了源代码方面的兼容性，APR还希望能够保持二进制之间的兼容性。通过保持二进制兼容，应用程序可以直接使用高版本的APR库(或者是DLL，或者使so文件)替换低版本的库文件，而不需要做任何修改，就可以链接成功。与源代码兼容一样，二进制的兼容也是向前兼容，而不保证向后兼容。
