这是我写的开源代码。
https://github.com/simkimsia/UtilityBehaviors/blob/master/README.mdown
我有No Stable Release
packagist.org
如何从packagist获得稳定发布贴纸？
答案 0 :(得分：36)
您必须使用版本号标记代码。
git tag -a 0.0.0
这将宣布第一个稳定版本。如果你担心全零版本号，你可以从0.0.1开始，如果你想要的话。如果可以，请尝试坚持语义版本控制：http://semver.org。之后，您应该将其推送到公共存储库，例如git push --tags。
请注意，您可以在代码中使用整个稳定性标签数组。有一些来自alphaer，beta，Composer认可的候选版本。有关如何创建版本号的信息，请参阅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}}用于API稳定但内部未完成的版本，然后1.0.0-beta1用于在最终错误修复阶段可能的API稳定的完成版本，然后1.0.0-rc1用于最终版本。更多错误修正将为1.0.0及以上，新功能将为1.0.1，不兼容的API更改将为1.1.0。请注意，第一批用户可能会使用2.0.0作为其版本要求，并且随着开发的进展，将始终获得最新的更新，而无需更改其要求（除非您破坏API并强制更新）。如果你走^1.0.0@beta路线然后将最终产品发布为0.x，这将永远不会有效，因为你至少有明显不兼容的更新跳转到1.0。
如果没有未来的知识，很难决定一个软件包是否有用并创建一个快乐的用户群（谁将受益于1.0.0发布标签），或者它只是一个有趣的实验，没有人使用在生产中（又名1.0.0@alpha）。
我个人对内部私有包的偏好是从一开始就让他们0.x。我必须处理从1.0开始的几个包，并且在更新时有点讨厌，因为它们已经成熟，但由于不兼容的版本步骤而无法转到0.0.1，这将涉及大量工作在二级包中。