摘要：
一系列版本兼容的软件库。（但添加这样的函数很简单）捆绑包的格式可能是library=version的列表：经过测试（该示例是假设的），发现这些版本的库可以一起工作——也就是说，兼容。捆绑包的使用意味着用户不必担心我要使用哪个版本的boost。他们只需要告诉编译系统。至于boost，qt，捆绑包的发布者向我保证，您可以将其视为版本查找表。
这里说的Bundle，是software library范畴的，我把它定义为： 一系列版本兼容的软件库。
对于比较小的项目，用的library不多，升级不勤快，这不是个问题，但是对于大型项目，bundle是非常有用的 - 当然，这需要build system的支持。（但加一个这样的功能蛮简单的）
bundle的格式大概为一个library=version的列表：
boost = 1.50qt = 4.8.3opencv = 2.4.2
意思是我把这几个lirary打成一个包，经测试（例子是假设的）发现这几个版本的library是可以在一起工作的 - 也就是说兼容的。
bundle的使用就是用户不需要去烦心我要用哪个版本的boost， 哪个版本的opencv等等，只需要告诉编译系统，我要用这个bundle， 至于boost，qt，opencv的版本是什么，直接到bundle里去查， bundle的发布者已经替我保证：这些个东西，是可以和睦相处的。
bundle本身不带入任何依赖，你可以把它看成一个版本查找表，从这个表里查到的版本，都是兼容的。
妈妈再也不用担心我用的这些library不互相兼容了。
所以，对于用户，这是一个很好的功能；
而对于库的发布者，比如你维护很多的library， bundle是一个非常好的组织、发布你的library的方法。
另外，你还可以扩展bundle。
比如一个库发布者发布了一个bundle A，而另外一个库的发布者B可以在A的基础上定义bundle，意在包含A， 从而用户在指定B的时候，也就自然包含了A。 这也是一个常用的场景，想象一下：
有三个application team， 他们共用一个framework B，并且用到了很多A中的library， 那么这个framework team就可以用这种方式作一个bundle B，这样对于application team来说，就只是简单的使用bundle B了。