web-dev-qa-db-ja.com

亀のSVNを介してリポジトリにプラグインを更新するための正しい方法は何ですか？

私のプラグインは何年も前からリポジトリにあり、30万を超えるダウンロードがあったにもかかわらず、私はべっこsvnを介してプラグインを更新するのに使われる手順に少し無知であると言うのは恥ずかしいです！

ここにはsvnについてたくさんの質問がありますが、彼らは私をさらに混乱させているだけです：-z

どういうわけか私はこれまで管理してきましたが、トランクをコミットしてtagsディレクトリを作成することに関して、自分のプラグインを新しいバージョンに更新するための適切な手順を知る必要があります。

これが私が今までしてきたことです。

  1. それがうまくいくまで、私のローカルでプラグインの更新をコーディングしてください。
  2. 自分のローカルプラグインフォルダ内のすべてのファイルを/ trunk /にコピーします（プラグインとreadmeファイルのバージョン番号が更新されました）。
  3. トランクディレクトリをコミットする
  4. trunkディレクトリを右クリックして、create branch/tagを選択し、/ tags /内のフォルダにコピーするように設定します。名前はバージョン番号です。

それは正しいですか、正しい順序ですか。そうでなければ、正しい方法は何ですか？

また、バージョン番号について...

何らかの理由で、前回のアップデートでバージョン2.8.1から2.81.2に移行しました。これは、次のバージョン番号をに変更した場合、バージョン2.81.2を持つ人々のダッシュボードにアップデートとして表示されないことを意味します。 2.9？

wordpressはどのバージョンが最新バージョンであるか、またユーザーが自分のバージョンを更新する必要があるかどうかをどのように判断しますか？それはversion_compareを行いますか？それは適切なPHPバージョンフォーマットでのみ動作しますか？例えば。 2.9.2は2.81.2より低いバージョンと見なされますか？ （なぜなら、私が理解しているように、version_compareは左側から始まり、各桁ごとに高い/低い値を比較するので、9は81より小さいと見なされるからです）

別の質問

私がプラグインの動作に実際には影響を与えないコードの愚かなミスを見つけた場合、おそらくタイプミスや追加の画像かもしれません。プラグインの新しいダウンロードに変更が含まれるようにするには、何を編集してコミットしますか？

トランクとタグフォルダを編集して両方をコミットする必要がありますか？

pluginsupdatesrepositorysvn
16
CommentLuv

私のプラグインは何年もリポジトリにあり、300,000以上のダウンロードがありましたが、亀のsvnを介してプラグインを更新するための手順については少し無知だと言って恥ずかしいです！

しないでください。 SVNは多くの人にとって扱いにくいものになる可能性があります。

これは私がこれまでやってきたことです。

  1. 満足するまでローカルでプラグインの更新をコーディングする
  2. ローカルプラグインフォルダー内のすべてのファイルを/ trunk /にコピーします（プラグインとreadmeファイルのバージョン番号が更新されています）
  3. トランクディレクトリをコミットする
  4. トランクディレクトリを右クリックし、[ブランチ/タグの作成]を選択して、バージョン番号を名前として/ tags /のフォルダーにコピーするように設定します。

それは正しいですか？正しい順序ですか？そうでない場合、正しい方法は何ですか？

ほぼ...

する必要があります次の手順：

  1. 満足するまでプラグインの更新をローカルでコーディングします
  2. 新しいバージョン番号に一致するようにreadme.txtファイルの「安定」タグを増やします
  3. ローカルアップデートをローカルプラグインフォルダーの/trunkディレクトリにコピーします
  4. プラグイン全体をコミットして、/trunkへの変更をリポジトリに保存します
  5. /trunkを右クリックして新しいタグを作成し、/tags/X.X.Xにコピーします。x.x.xはreadme.txtの「stable」タグと同じバージョンです（ステップ2）
  6. プラグイン全体をコミットしてタグを保存します

何らかの理由で、前回のアップデートでバージョン2.8.1から2.81.2に変更しました。これは、次のバージョン番号を次のバージョン番号に変更した場合、バージョン2.81.2のユーザーのダッシュボードにアップデートとして表示されないことを意味します2.9？

ビンゴ。バージョン2.81.2を更新としてコミットし、人々が実際にその更新をダウンロードした場合、リリース時に2.9は表示されません。

wordpressは、どのバージョンが最新バージョンであり、ユーザーがバージョンを更新する必要があるかをどのように決定しますか？ version_compareを実行しますか？適切なPHPバージョン形式でのみ動作しますか？例えば。 2.9.2は2.81.2よりも低いバージョンと見なされますか？ （私が理解しているように、version_compareは左から始まり、各数字の上位/下位を比較するため、9は81未満と見なされます）

まさに。標準のPHPバージョン比較では、バージョン2.81.2は、81> 9であるため、2.9よりも新しいバージョンであると見なされます。

次にバージョン3.0をリリースすることをお勧めします。その後、この種のタイプミスを防ぐために、今後バージョン管理する際は非常に注意になるようにしてください。

プラグインの動作に実際には影響しないコードのばかげた間違いを見つけた場合は、タイプミスや追加の画像があります。プラグインの新しいダウンロードに変更が含まれるようにするには、何を編集してコミットしますか？

トランクとタグフォルダを編集して両方をコミットする必要がありますか？

小さな変更を加える必要がある場合は、メンテナンスリリースと考えてください。通常、この種のバージョン管理スキーマに従います。

2      .      1       .       3       .       5
major         minor           maint           build

社内またはベータリリースでのみ使用するビルド番号...手動でファイルをメールで送信しない限り、ほぼneverからビルド番号が表示されます（これにより、プレリリースバージョンを配布できます） WordPress更新を中断しないでください）。

ライブバージョンのバグに気付いた場合は、簡単なパッチを作成してメンテナンスバージョンをリリースします。プラグインのバージョン2.2をリリースし、noConflict（）モードでjQueryを呼び出すのを忘れたことに誰かが気付いたとします。クイックパッチを適用し、すぐに2.2.1をリリースします。

バージョンの増分により、WordPressが更新を認識し、バージョン2.2を既にインストールしているすべてのユーザーに修正を提供します。

メンテナンスバージョンをリリースするには、システムのフルバージョンをリリースしているかのようにまったく同じ手順に従う必要があります。したがって、変更を行い、readme.txtのバージョンを増やし、/trunkをコミットし、タグなどを追加します。

ただし、一度タグを付けたら、二度と変更することはありません。/tagsフォルダーが時間の経過とともにフリーズしていると考えてください。そのフォルダー内の各バージョンは、特定の時点でのプラグインのスナップショットです。never/tagsフォルダー内のファイルを直接変更する必要があります。

あなたがそれが良い考えかもしれないと思うなら、頭の後ろで自分自身を叩いて、代わりにメンテナンスバージョンをリリースしてください:-)

Pietが述べたように、私は 以前の段階的な手順の良いセット ...を書いたが、サイトはスクリーンショットを失ったようだ。私のサイトでホストされているTortoiseのスクリーンショット付きの同じステップバイステップガイドの別のバージョンを次に示します。 http://eamann.com/tech/how-to-publish-a-wordpress-plugin-Subversion/

27
EAMann