15

これは私が書いたオープン ソース コードです。

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

私はNo Stable Releaseから持っていますpackagist.org

から安定版リリースのステッカーを取得するにはどうすればよいpackagistですか?

4

1 に答える 1

39

コードにバージョン番号をタグ付けする必要があります。

git tag -a 0.0.0

これにより、最初の安定版が宣言されます。すべてゼロのバージョン番号が心配な場合は、必要に応じて 0.0.1 などから始めることができます。可能であれば、セマンティック バージョニングに固執するようにしてください: http://semver.org。その後、 を のように公開リポジトリにプッシュする必要がありますgit push --tags。

タグで安定性ラベルの配列全体を使用できることに注意してください。Composer が認識するアルファ、ベータ、リリース候補のすべてがあります。バージョン番号の作成方法については、 http: //getcomposer.org/doc/04-schema.md#versionを参照してください。

次に、Packagist はリポジトリをスキャンし、そのタグを処理します。これは「安定した」リリースであり、それに応じてパッケージにマークを付けます (バージョン番号が 0.0.0 の場合でも、Composer に関しては 0.x ソフトウェアは 24.x ソフトウェアと違いはありません)。 /Packagist)。

編集 2016-07-14

セマンティック バージョニングでは、バージョン番号が で始まる場合、異なる方法で処理されることに注意してください0.x.y。これは、タグ付けとリリースにはまったく影響しませんが、リリースされたソフトウェアをユーザーが選択して更新する方法に影響します。0.x次のマイナー アップデートをリリースすると、この範囲内のソフトウェアはすべて非互換と見なされます0.x+1。Composer チルダ演算子~は、これによって妨げられることはありません: ~0.x(x として任意の整数を使用) は、次のマイナー バージョンに更新されます。キャレット演算子は異なる動作をします:^0.xまたは範囲内^0.x.yにとどまり、どのリリースにも移動しません。0.x0.x+1.y

これに対抗する最善の方法は、1.xバージョンから開始し、安定性フラグを使用して変更の可能性を示すことです。1.0.0-alpha1の代わりに最初のリリースとして使用できます0.0.1。以降のリリースは1.0.0-alpha2、別の「不安定な」(読み取り: API 未完成/安定) リリース1.0.0-beta1用1.0.0-rc1である可能性があります。最終的なバグ修正段階でリリースを終了し、その後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.0@alpha) のか、それとも本番環境で誰も使用していない単なる興味深い実験 (別名0.x) なのかを、将来の知識なしに判断するのは困難です。

内部プライベート パッケージに対する私の個人的な好みは1.0、最初から作成することです。で開始されたいくつかのパッケージに対処する必要が0.0.1あり、それらは成熟しているため更新時に少し厄介ですが1.0、互換性のないバージョンステップのために移動できません。これには、セカンダリパッケージで多くの作業が必要になります。

于 2013-11-07T21:06:52.627 に答える