如何更改 packagist 的标签以获得稳定版本? [英] How do I change the packagist sticker for stable release?

问题描述

这是我写的开源代码.

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

我有一个来自 packagist.org

如何获得 packagist 的稳定版本标签?

How do I go about having a Stable Release sticker from packagist?

推荐答案

你必须用版本号标记你的代码.

You have to tag your code with a version number.

git tag -a 0.0.0

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

That will declare the first stable version. If you worry about an all-zero version number, you can start with something like 0.0.1 if you want. Try to stick to semantic versioning if you can: http://semver.org. After that you should push the to the public repository, like git push --tags.

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

Note that you can use the whole array of stability labels in your tags. There is everything from alpha, beta, release candidate recognized by Composer. See http://getcomposer.org/doc/04-schema.md#version for info on how to create a version number.

Packagist 然后会扫描您的存储库并处理该标记，这是一个稳定"版本，并相应地标记您的包(即使版本号为 0.0.0 - 0.x 软件与 24.x 软件在Composer/Packagist 的术语).

Packagist will then scan your repository and process that tag, which is a "stable" release, and mark your package accordingly (even with the 0.0.0 version number - 0.x software is not different from 24.x software in terms of Composer/Packagist).

编辑 2016-07-14

请注意，如果语义版本控制中的版本号以 0.x.y 开头，则它们的处理方式会有所不同.这不会以任何方式影响标记和发布，但会影响用户选择和更新您发布的软件的方式.如果您发布下一个次要更新 0.x+1，则 0.x 范围内的任何软件都被认为是不兼容的.Composer 波浪号运算符 ~ 不会受此影响:~0.x(任何整数为 x)将更新到下一个次要版本.插入符号运算符的行为会有所不同:^0.x 或 ^0.xy 将保持在 0.x 范围内，不会转到任何0.x+1.y 发布.

Note that version numbers in semantic versioning are handled different if they start with 0.x.y. This does not affect tagging and releasing in any way, but it affects the way users can select and update your released software. Any software in the 0.x range is considered an incompatible if you release the next minor update 0.x+1. The Composer tilde operator ~ will not be disturbed by this: ~0.x (with any integer as x) will update to the next minor version. The caret operator will behave different: ^0.x or ^0.x.y will stay in the 0.x range and not go to any 0.x+1.y release.

解决此问题的最佳方法是从 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 将出现新功能，2.0.0 将出现不兼容的 API 更改.请注意，第一批用户可能会使用 ^1.0.0@beta 作为他们的版本要求，并且随着开发的进行，将始终获得最新的更新而无需更改他们的要求(除非您破坏了您的 API 和以这种方式强制更新).如果您走 0.x 路线然后将最终产品发布为 1.0.0，这将永远不会起作用，因为您至少有明显的不兼容更新跳转到 1.0.

The best way to counter this would be to start with 1.x versions, and use stability flags to indicate possible changes. You can use 1.0.0-alpha1 as your first release instead of 0.0.1, later releases may be 1.0.0-alpha2 for another "unstable" (read: API not finished/stable) release, then go to 1.0.0-beta1 for API-stable, but internally unfinished releases, then 1.0.0-rc1 for possibly API-stable, finished releases during final bugfixing phase, and then 1.0.0 for the final release. More bugfixes will be 1.0.1 and up, new features will be 1.1.0, incompatible API changes will be 2.0.0. Note that the first users may use ^1.0.0@beta as their version requirement, and as development progresses, will always get the newest update without the need to change their requirement (unless you break your API and force updates that way). This will never work if you go the 0.x route and then release the final product as 1.0.0, because you have at least the obvious incompatible update jump to 1.0.

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

It's hard to decide without future knowledge whether a package proves to be useful and creates a happy user base (who will benefit from a 1.0.0@alpha release tag), or if it is only an interesting experiment that nobody is using in production (a.k.a. 0.x).

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

My personal preference for internal private packages is to make them 1.0 from the start. I have to deal with several packages that started at 0.0.1 and are a bit nasty when updating because they are mature, but cannot go to 1.0 because of that incompatible version step, which would involve a lot of work in secondary packages.

这篇关于如何更改 packagist 的标签以获得稳定版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！