tangq 的投稿 | PHP 技术论坛

修改描述，有点混乱

Old	New	Differences
19	19	}
20	20	```
21	21
22		在上例中，项目名是 `acme/hello-world`，其中 `acme` 是当前项目出处名称，该名称是必须的。
	22	在上例中，项目名是 `acme/hello-world`，其中 `acme` 是当前项目出处名称，如果它被设计为可以被其他人安装，该名称是必须的。
23	23
24	24	> 注意：如果你不知道该使用什么作为提供者名称，你的 GitHub 用户名是个不错的选择。虽然包的名称不区分大小写，但通常采用全部小写，使用破折号分离单词。
25	25
26	26
27		库版本
	27	库(包)版本
28	28	------------------
29	29
30		在绝大数情况下，你将使用某种版本控制系统（如 git、svn、hg 或 fossil）来维护你的库。在这些情况下，Composer 会从你的 VCS 中推断出版本，并且你不应该在 `composer.json` 中把版本写死。（请看 [Versions 文章](https://github.com/composer/composer/blob/master/doc/articles/versions.md) ）了解 Composer 如何使用 VCS 分支和标记来解决版本约束。
	30	在绝大数情况下，你将使用某种版本控制系统（如 git、svn、hg 或 fossil）来维护你的库(包)。在这些情况下，Composer 会从你的 VCS 中推断出版本，并且你不应该在 `composer.json` 中把版本写死。（请看 [Versions 文章](https://github.com/composer/composer/blob/master/doc/articles/versions.md) ）了解 Composer 如何使用 VCS 分支和标记来解决版本约束。
31	31
32	32	如果你手动维护（即没有 VCS），你需要通过在 `composer.json` 文件中添加一个 `version` 值来明确指定版本：
33	33
…	…
60	60
61	61	一旦你有一个包含 `composer.json` 文件的版本仓库（例如 Git）,你的库就总是可以被 Composer 安装的。在这个例子里我们会把 `acme/hello-world` 库发布到 Github 的 `github.com/username/hello-world` 中。
62	62
63		现在，为了测试 `acme/hello-world` 包，我们本地创建了一个项目。我们叫它 `acme/blog`。这个 blog 项目会依赖 `acme/hello-world`~~，反过来它也依赖 `monolog/monolog`~~。我们可以在某处创建一个包含 `composer.json` 文件的 `blog` 目录来完成它：
	63	现在，为了测试 `acme/hello-world` 包，我们本地创建了一个项目。我们叫它 `acme/blog`。这个 blog 项目会依赖 `acme/hello-world`。我们可以在某处创建一个包含 `composer.json` 文件的 `blog` 目录来完成它：
64	64
65	65	```
66	66	{
…	…
71	71	}
72	72	```
73	73
74		因为我们不会把 blog 作为一个库去发布，所以 name 字段不是必须的。 ~~它被添加到这里是为了阐明哪个 `composer.json` 是被描述的。~~
	74	因为我们不会把 blog 作为一个库去发布，所以 name 字段不是必须的。
75	75
76	76	现在我们需要告诉 blog 应用去哪找 `hello-world` 依赖。我们通过向 `composer.json` 文件添加 repositories 项来完成此工作：
77	77

Old

New

Differences

}

```

在上例中，项目名是 `acme/hello-world`，其中 `acme` 是当前项目出处名称，该名称是必须的。

在上例中，项目名是 `acme/hello-world`，其中 `acme` 是当前项目出处名称，如果它被设计为可以被其他人安装，该名称是必须的。

> 注意：如果你不知道该使用什么作为提供者名称，你的 GitHub 用户名是个不错的选择。虽然包的名称不区分大小写，但通常采用全部小写，使用破折号分离单词。

库版本

库(包)版本

------------------

在绝大数情况下，你将使用某种版本控制系统（如 git、svn、hg 或 fossil）来维护你的库。在这些情况下，Composer 会从你的 VCS 中推断出版本，并且你不应该在 `composer.json` 中把版本写死。（请看 [Versions 文章](https://github.com/composer/composer/blob/master/doc/articles/versions.md) ）了解 Composer 如何使用 VCS 分支和标记来解决版本约束。

在绝大数情况下，你将使用某种版本控制系统（如 git、svn、hg 或 fossil）来维护你的库(包)。在这些情况下，Composer 会从你的 VCS 中推断出版本，并且你不应该在 `composer.json` 中把版本写死。（请看 [Versions 文章](https://github.com/composer/composer/blob/master/doc/articles/versions.md) ）了解 Composer 如何使用 VCS 分支和标记来解决版本约束。

如果你手动维护（即没有 VCS），你需要通过在 `composer.json` 文件中添加一个 `version` 值来明确指定版本：

…

一旦你有一个包含 `composer.json` 文件的版本仓库（例如 Git）,你的库就总是可以被 Composer 安装的。在这个例子里我们会把 `acme/hello-world` 库发布到 Github 的 `github.com/username/hello-world` 中。

现在，为了测试 `acme/hello-world` 包，我们本地创建了一个项目。我们叫它 `acme/blog`。这个 blog 项目会依赖 `acme/hello-world`~~，反过来它也依赖 `monolog/monolog`~~。我们可以在某处创建一个包含 `composer.json` 文件的 `blog` 目录来完成它：

现在，为了测试 `acme/hello-world` 包，我们本地创建了一个项目。我们叫它 `acme/blog`。这个 blog 项目会依赖 `acme/hello-world`。我们可以在某处创建一个包含 `composer.json` 文件的 `blog` 目录来完成它：

```

{

…

}

```

因为我们不会把 blog 作为一个库去发布，所以 name 字段不是必须的。 ~~它被添加到这里是为了阐明哪个 `composer.json` 是被描述的。~~

因为我们不会把 blog 作为一个库去发布，所以 name 字段不是必须的。

现在我们需要告诉 blog 应用去哪找 `hello-world` 依赖。我们通过向 `composer.json` 文件添加 repositories 项来完成此工作：

修改理由：

相关信息：

内容修改：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息