如何更改包装贴纸以稳定释放？

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.之后你应该推送到公共存储库,比如git push --tags.

请注意,您可以在标记中使用整个稳定性标签数组.有一些来自alphaer,beta,Composer认可的候选版本.有关如何创建版本号的信息,请参见http://getcomposer.org/doc/04-schema.md#version.

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

编辑2016-07-14

请注意,语义版本控制中的版本号如果以它们开头则处理不同0.x.y.这不会以任何方式影响标记和释放,但会影响用户选择和更新已发布软件的方式.0.x如果您发布下一个次要更新,则该范围内的任何软件都被视为不兼容0.x+1.Composer tilde运算符~不会受到此干扰:( ~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-beta1API稳定但内部未完成的版本,然后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由于不兼容的版本步骤而无法访问,这将涉及在二级软件包中的大量工作.