如何更改 Packagist 稳定版本的贴纸？

Question

这是我编写的开源代码。

https://github.com/simkimsia/UtilityBehaviors/blob/master/README.mdown

我从packagist.org获得了一个无稳定版本的版本。

我该如何获得来自packagist的稳定版本？

- Kim Stacks

Answer 1

你需要在你的代码中加上一个版本号标签。

git tag -a 0.0.0

那将宣布第一个稳定版本。如果你担心全零的版本号，你可以从0.0.1开始。如果可能，请尽量遵循语义化版本控制：http://semver.org。之后，您应该将其推送到公共存储库中，例如git push --tags。

请注意，您可以在标记中使用稳定性标签的整个数组。 Composer承认Alpha、Beta、Release Candidate等所有内容。有关如何创建版本号的信息，请参见http://getcomposer.org/doc/04-schema.md#version。

Packagist将扫描您的存储库并处理该标记，这是一个“稳定版”，并相应地标记您的软件包（即使版本号为0.0.0- 0.x软件与24.x软件在Composer/Packagist方面没有区别）。

编辑2016-07-14

请注意，如果语义化版本控制中的版本号以0.x.y开头，则处理方式不同。这对标记和发布不会产生任何影响，但它会影响用户选择和更新您发布的软件的方式。 0.x范围内的任何软件都被视为不兼容，如果您发布下一个较小的更新0.x+1。 Composer波浪符操作符~不会受此影响：~0.x（任何整数作为x）将更新到下一个较小的版本。插入操作符将有所不同：^0.x或^0.x.y将保留在0.x范围内，不会转到任何0.x+1.y版本。

抵消这种情况的最佳方法是从1.x版本开始，并使用稳定性标志指示可能的更改。您可以使用1.0.0-alpha1作为第一个发布版本，而不是0.0.1，稍后的版本可以是1.0.0-alpha2用于另一个“不稳定”（即：API未完成/稳定）版本，然后转到1.0.0-beta1用于API稳定但内部未完成的版本，然后再到1.0.0-rc1用于在最后的bug修复阶段可能稳定的、已完成的版本，然后1.0.0为最终版本。更多的错误修复将是1.0.1及以上，新功能将是1.1.0，不兼容的API更改将是2.0.0。 请注意，第一批用户可以使用^1.0.0@beta作为其版本要求，并且随着开发的进展，将始终获得最新的更新，而无需更改其要求（除非您打破API并通过强制更新来实现）。如果您选择使用0.x路线，然后将最终产品发布为1.0.0，这永远不会起作用，因为您至少需要明显的不兼容更新跳转到1.0。

在没有未来知识的情况下，很难决定软件包是否证明有用并创建了一个快乐的用户群（将受益于1.0.0@alpha发布标签），

- Sven

---

我注意到我添加的 git push --tags 的编辑不再存在。我认为这是答案的重要部分。可以加上吗？ - Kim Stacks

五位评审员中有四位拒绝了那个编辑。我认为标签应该自然地放在被 Packagist.org 扫描的代码库内，所以你需要推送它。 - Sven

我接受他们的决定。说实话，作为一个对标签概念初学者，我不得不通过谷歌搜索来找到确切的推送命令。我想帮助其他初学者避免这种麻烦。 - Kim Stacks

你说得很有道理。我已经把那个提示加到我的答案里了，尽管它现在已经在评论中提到了。 :) - Sven

人们：Packagist会缓存一些东西。在使用标签（tags）时，记得更新Packagist后静静等待几分钟再运行composer update，保持冷静。 - Félix Adriyel Gagnon-Grenier