随着 发布前检查列表完成，现在是时候让我们的包可以供其他人使用。
包的使用者很有可能使用 Composer 来管理他们项目中的依赖项。为了使包与 Composer 兼容，我们需要执行以下几个步骤。
标记发布
为了让我们的用户有效地管理他们的依赖项，正确发布包的新版本非常重要。
对代码进行版本控制最常见的方法是遵循 语义化版本控制。这定义了一套“规则和要求，规定了版本号的分配和递增方式”。在网站上，这些定义为
- 当您进行不兼容的 API 更改时，使用 MAJOR 版本。
- 当您以向后兼容的方式添加功能时，使用 MINOR 版本。
- 当您进行向后兼容的错误修复时，使用 PATCH 版本。
用于预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展使用。
如果您有兴趣，可以在网站上找到完整定义。
决定为您的初始发布标记哪个版本可能很棘手，我最近在 Twitter 上看到了一条关于这个问题的有趣帖子。
语义化版本控制建议，如果您正在生产环境中使用该包，您应该直接使用 1.0.0，但如果还没有，而且该包仍在开发中，则初始发布应该使用 0.1.0。
标记发布的方法不止一种。在本文中，我将向您展示如何在 GitHub 上执行此操作。
在您的存储库根目录中，单击“发布”，然后单击“创建新发布”。
在其中，在“标签版本”字段中输入您想要的版本号，并选择要引用的目标。这可以是一个分支或一个单独的提交。如果您愿意，您也可以提供一个合适的标题，我通常使用版本号作为标题。
您还可以提供发布说明，这是一种很好的方法，可以让用户了解确切的更改内容，甚至可以感谢您的贡献者。
提交到 Packagist
现在，为了让用户能够使用 Composer 轻松安装该包，通常会将其发布到 Packagist。
为此，请登录您的 Packagist 帐户，并在主导航栏中单击“提交”。在提示时输入您的 Git 存储库的 URL。
Packagist 将从 composer.json 文件中提取所有相关信息，并将包发布到存储库，以便人们使用。该包现在将在该网站上拥有自己的页面，为用户提供安装次数、版本和最新活动等详细信息。
总结
发布了包，并可以供人们使用，我们已经到了本系列文章的最后。
现在，我们进入常规业务，发布包的新版本，处理用户提交的问题和拉取请求。
我真心希望您喜欢本系列文章，并从中获得一些有用的技巧。像往常一样，如果您有任何问题或意见，请在 Twitter 上发送给我们。
