在前面中曾得到包依赖声明，如下：
{
"require": {
"mustache/mustache": "2.0.*",
"monolog/monolog": "1.0.*"
}
}本节将详细说说require中依赖包的名称及其版本号。
包名称由其供应商名称和项目名称构成。
由于不同供应商（开发者），对于同一问题都可能做出自己的解决方案项目，往往会有相同的名称，所以在项目名称前加上供应商即可避免因项目同名而造成的混乱，就如同命名空间一样，同一个项目中，不同命名空间下都可以有名称都为Order的类却不会造成冲突。
mustache/mustache的供应商为“mustache”，项目名为“mumstache”，如果我也创建了一个相似的项目，并且也以“mustache”作为项目名，那么我提供给别人使用时，整个包名可能就是“daijl/mustache”了，当然，“daijl”是供应商名称。
对于一个具有唯一名称的项目，一般建议建立一个同名的供应商，就像“mustache/mustache”和“monolog/monolog”一样，好处是显而易见的，这样可以对项目进行进一步地细分，将项目拆解成若干个细分的子项目，并在主项目中声明依赖这些子项目，更便于维护。
包版本号有以下几种方式来指定：
1. 确切的版本号
例如：1.0.2 2.2.3
composer将只安装这一个版本。如果其他包依赖本包并且要求是本包的另一个版本，composer将解析失败并终止安装或更新程序。
2. 通配符“*”
例如：1.0.* 2.2.* 3.*
你可以使用通配符“*”来指定一种模式。1.0.*与>=1.0,<1.1是等效的。
3. 比较操作符指定版本范围
例如：>=1.0 >=1.0,<2.0 >=1.0 <1.1||>=1.2
通过使用比较操作符可以指定有效的版本范围。
有效的运算符：>、>=、<、<=、!=。
你可以定义多个范围，用空格或逗号隔开，这将被视为一个逻辑AND处理。一对管道符号“||”将作为逻辑OR处理。AND 的优先级高于 OR。
注意：如果没有限制边界，如>2，有可能会意外地安装了一个不兼容的版本，例如供应商发布了3.0版本，且这个版本不与2.X版本兼容，就会引发问题。建议限制好边界，一般同一个大版本范围内的小版本是兼容的，可以以此限制条件，当然具体情况还要看依赖包的版本兼容情况。
4. 连字符“-”指定版本范围
例如：1.0 - 2.0 1.0.0 - 2.1.0
版本范围为：>= 左 AND <= 右.*
1.0 - 2.0表示版本 >=1.0.0 并且 <2.1 （<2.1 即相当于 2.0.*）
1.0.0 - 2.1.0 表示版本 >=1.0.0 并且 <=2.1.0
1. 波浪线“~”
例如：~1.2，表示>=1.2 <2.0.0，~1.2.3表示 >=1.2.3 <1.3.0，规律就是“~”后面的版本号的最后一节数字可变且不小于该数字，前面的内容不可变。
此方法非常有用，常被用来声明所依赖的最小次要版本。
2. 插入符“^”
与波浪线的表现有点相似，但可变的版本节点不同。例如^1.2.3 表示 > = 1.2.3 < 2.0.0，而 0.3 表示 >=0.3.0 <0.4.0。“^”使版本号的第一个有效数字节点（版本第一节为0的不算）保持不变，后续节点不低于声明的内容，根据例子很容易理解。