这是我写的开源代码。
https://github.com/simkimsia/UtilityBehaviors/blob/master/README.mdown
我有packagist.org的No Stable Release
我如何获得packagist的稳定版本贴纸？
您必须使用版本号标记代码。
git tag -a 0.0.0
这将声明第一个稳定版本。如果您担心全零版本号，如果需要，可以从 0.0.1 开始。如果可以的话，尝试坚持语义版本控制：http://semver.org。之后，您应该将 推送到公共存储库，例如 git push --tags .
请注意，您可以在标签中使用整个稳定性标签数组。有从 alpha、beta、作曲家认可的候选版本的所有内容。有关如何创建版本号的信息，请参阅 http://getcomposer.org/doc/04-schema.md#version。
然后，Packagist将扫描您的存储库并处理该标签，这是一个"稳定"版本，并相应地标记您的软件包（即使使用 0.0.0 版本号 - 0.x 软件在 Composer/Packagist 方面与 24.x 软件没有什么不同）。
编辑 2016-07-14
请注意，如果语义版本控制中的版本号以 0.x.y 开头，则处理方式会有所不同。这不会影响标记和发布，但会影响用户选择和更新已发布软件的方式。如果您发布下一个次要更新0.x+1，则0.x范围内的任何软件都被视为不兼容。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。
如果没有未来的知识，很难决定一个包是否被证明是有用的并创建了一个快乐的用户群（他们将从1.0.0@alpha发布标签中受益），或者它只是一个有趣的实验，没有人在生产中使用（又名 0.x ）。
我个人对内部私有包的偏好是从一开始就使它们1.0。我必须处理几个从0.0.1开始的软件包，并且在更新时有点讨厌，因为它们已经成熟，但由于不兼容的版本步骤而无法进入1.0，这将涉及大量工作在辅助软件包中。