github - 如何更改 packagist 的标签以获得稳定版本？

Question

这是我写的开源代码。

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

我有一个 No Stable Release来自 packagist.org
如何获得 packagist 的稳定版本标签？ ?

Answer 1

您必须使用版本号标记您的代码。

git tag -a 0.0.0

这将宣布第一个稳定版本。如果您担心全零版本号，可以根据需要从 0.0.1 之类的内容开始。如果可以，请尝试坚持语义版本控制: http://semver.org 。之后，您应该将其推送到公共(public)存储库，例如 git push --tags 。

请注意，您可以在标签中使用整个稳定性标签数组。 Composer 认可了从 alpha、beta 到发布候选的所有内容。有关如何创建版本号的信息，请参阅 http://getcomposer.org/doc/04-schema.md#version。

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

编辑 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 用于可能是 API 稳定的，在最后的错误修复阶段完成的版本，然后是 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。

如果没有 future 的知识，很难决定一个包是否被证明是有用的并创造了一个快乐的用户群(他们将从 1.0.0@alpha 发布标签中受益)，或者它是否只是一个没有人在生产中使用的有趣实验(又名 0.x )。

我个人对内部私有(private)包的偏好是从一开始就将它们设为 1.0。我必须处理几个从 0.0.1 开始的包，并且在更新时有点讨厌，因为它们已经成熟，但由于版本不兼容的步骤而无法转到 1.0，这将涉及到二级包的大量工作。