Amqp: goモジュールのサポート

👍semverを採用してください。 以前はhttps://github.com/streadway/amqp/issues/312で閉鎖されていました

＃312への答えが今日何であるかに完全に依存していると思います。 @streadwayあなたはこれについてもう一度議論することにオープンですか？

Go ModulesやSemVerなど、変更の価値提案についてお話しさせていただきます。 例で裏付けられたケースを作ってください。

私が取り組んでいる現在のケースは、date + shaラベリングよりもxyzラベリングの個人的な好みです。そのため、メンテナンスタスクや回帰を例として、好み以外のものの長所と短所を提示して議論する方が簡単です。

@streadwayご回答ありがとう

そのステートメントに色を追加するには：

1. Goは、SemVerhttps ：//github.com/golang/go/wiki/Modules#semantic-import-versioningの使用を公式に推奨してい
2. GoモジュールはGo依存関係管理の未来です（未来は今です！）

このリポジトリは、モジュールの最も単純なケースの1つです（外部の部門や既存のリリースはありません）。 必要な作業は次のとおりです。go.modを追加し、タグとしてv1.0.0をリリースし、Go1.11以降でモジュールモードを使用するようにTravisCIテストをマイナーアップデートします。

SemVerタグ付きリリースを使用すると、将来発生する可能性のある重大な変更も可能になります。 可能性は低いですが、柔軟性があると便利です。

このパッケージのすべての作業に感謝します。また、👍を与えるたびにモジュールPRをまとめることができてうれしいです。

7年目に入ったライブラリの場合、変更が必要になる可能性はほとんどありません。API設計で避けられない間違いはすべて、初期の頃よりもはるかに明白になっているためです。 これは、Go側から自然に発生するすべての変更を無視した場合でも同様です。

私が聞いているのは、重大な変更が望まれており、インポートバージョン管理の推奨事項では、タグを使用する代わりに別のモジュール名を使用することを提案しています。 これにより、バグ修正をさまざまなメジャーバージョンにバックポートするために、さまざまなブランチを使用してリポジトリが効果的にフォークされます。

モジュールがバージョンv2以降の場合、モジュールのメジャーバージョンは、go.modファイルで使用されるモジュールパスの最後に/ vNとして含まれている必要があります（例：モジュールgithub.com/my/mod/v2、require github.com/my/mod/v2 v2.0.0）およびパッケージインポートパス（例：import "github.com/my/mod/v2/mypkg"）。

HEADを追跡するためのパッケージ名を含むgo.modを追加しても問題ありません（これは基本的に今日行っていることです）。 寄稿者向けに文書化されたタグ付きコミットのリリースプロセスはまだないため、タグ付きコミットのプロセスと価値はまだ不明です。 リリースプロセスの文書化は別の問題です。

タグ付けとgo.mod（簡単です）について話す代わりに、必要な重大な変更とは何か、リリースを2つのモジュールにフォークするのに十分な価値があるかどうかについて説明しましょう。

@michaelklishin amqp/v2問題をリードして、API改善のロードマップを収集していただけませんか。 v2で作業する時間はほとんどないので、重大な変更が実装され、サポートされ、このパッケージのforkを新しいメジャーバージョンに保証するのに十分な価値があることを現実的にする必要があります。

最初にリリースプロセスとv2マイルストーンを文書化することについてのWDYT？

誤解しているかもしれませんが、v2 APIで動作するようにこのリポジトリをフォークする必要はありますか？

マスターの現在の状態がv1としてタグ付けされている場合、インポートをv1にロックしたい人は誰でも、自分のgo.modファイルでロックできます。 v2は独自のブランチで開発し、準備ができたらマスターにリリースできます。

また、goモジュールの一般的なサポートを追加します-それが、サポートが機能しているかどうかを確認するためにここに来た理由です:)

誤解しているかもしれませんが、v2 APIで動作するようにこのリポジトリをフォークする必要はありますか？

これは「Githubフォーク」ではなく、モジュールのアドレス指定可能性であり、モジュールごとに複数のHEAD参照を維持します。 メジャーバージョンごとに異なるモジュール名を使用することをお勧めします。

• v1（今日）のモジュール名はgithub.com/streadway/amqpます。
• v2（推奨）のモジュール名はgithub.com/streadway/amqp/v2ます。

バグ修正とv1関連の改善を行ったv1ブランチと、同様のバグ修正とv2関連の改善を行った別のAPIを備えたv2ブランチを維持します。 各HEADのコミットは、引き続きこのgitリポジトリに存在します。

v2は独自のブランチで開発し、準備ができたらマスターにリリースできます。

go.modを持たないv1APIに依存している場合、またはgo.modにrequireステートメントを追加していない場合、v2をマスターにマージするとどのような影響がありますか？

これは「Githubフォーク」ではありません

分かりました。 Goモジュールの私の経験は、主に消費者側からのものです。

go.modを持たないv1APIに依存している場合、またはgo.modにrequireステートメントを追加していない場合、v2をマスターにマージするとどのような影響がありますか？

彼らがベンダーを出していないと仮定すると、それは壊滅的な変化になるでしょう。 しかし、それは依存関係を管理しないことによって彼らが取っているリスクです。 このように広く使用されているパッケージにとって、なぜそれが正当な問題であるのかはわかりますが。

@streadway喜んでやりますが、計画を理解する必要があります。 複数のブランチを持つ単一のリポジトリが存在できない理由をまだ完全には理解していません。それは他のすべてのクライアントが行うことです。 数年ごとのAPIの変更は、業界の大多数（または少なくとも私がやり取りする部分）によって合理的であると見なされています。 このクライアントとそれが実装するプロトコルは、長年にわたって非常に安定しています。
2012年以降のクライアントは、引き続き接続してほとんどの機能を使用できます。

デフォルトのブランチを1.xに移動し、現在のAPIを保持して、この変更を発表し、数か月以内に1.xからの変更と相違点の統合と文書化を開始してみませんか。 私は他のクライアントと何年も同じようなことをうまくやっています。 これが、RabbitMQおよびTier1プラグインの開発方法でもあります。

一部のユーザーはアナウンスをまったく見ず、それに基づいて行動しないことを理解していますが、ブランチを変更する場合は、正直なところ、それは彼らの問題です。

私が気に入らない別の解決策は、GitHubフォークのようにこのプロジェクトをフォークし、パッケージ名を変更し、それをRabbitMQ組織に移動して、他のクライアントとRabbitMQ自体に使用される手法を採用することです。 このパッケージの現在のユーザーは、このプラグインを引き続き使用します。このプラグインは、破損しない修正のみを取得します。

これにより最初は多くの混乱が生じると思います。RabbitMQチュートリアルが「新しいクライアント」に切り替わると、このプラグインは最終的にほとんど注目されなくなります。

特にAPIに大幅な変更を加える予定がないことを考えると、これは多くのレベルで気に入らない。
Javaおよび.NETクライアントは、過去2年間でさらに重要な変更が加えられており、さらに多くの変更が計画されています。 誰もがこれらのクライアントで.NETCore、最新のJava言語機能などを使用したいと考えているため、コミュニティの反応は実際には非常に好意的です。

この会話を乗っ取って申し訳ありませんが、最初にマルチリリースシリーズの戦略を理解してから、Goエコシステムの必然的な未来であっても、Goモジュールがどのように適合するかを確認する必要があると感じています。
@AlexRuddは、似たようなものを提案しているようですが、同意しますか？

このコメントとこのコメントは、バージョン0.13.0 （ stable ）と今後の1.0.0リリース（ master ）に関してPikaプロジェクトで使用されるバージョンと分岐ワークフローをほぼ説明しています。

このプロジェクトでは、ある時点でgo.modをmasterに追加し、 v1.0.0タグを付けることができます。 その後、修正はセマンティックバージョニングに従います。 将来のある時点でmasterに後方互換性のない変更が加えられると、 v2名がモジュール名に追加され、前のコミットがv1将来の修正のベースになります。 v1ブランチの修正（呼び出されたものは何でも）は、必要に応じてmasterフォワードマージできます。 とにかく、私の$ 0.02

最初にリリースプロセスとv2マイルストーンを文書化することについてのWDYT？

少し軌道から外れました。 つまり、go modを使用して潜在的なリリースプロセスを形式化し、v2リリースを正当化するAPIの変更を提案しているのでしょうか。

goモジュールの定期的なリリースを行っている人の経験を聞いてみたいと思います。 また、これをうまく行っている他のリポジトリの例。

このコンテキストでは、重大な変更、つまりv2について説明する必要はないと思います。

モジュールは、モジュールにオプトインしていないパッケージを消費できますか？ 必要なのはgit tag v1.0.0だけだと思います。 これを行わないと、このパッケージがモジュールで必要になると、 v0.0.0-20171006230638-a6e239ea1c69 _などの_pseudo-versionになります。

v1を導入し、安定したAPIにコミットすることを決定したら（これは当然の結論です）、重大な変更について話し合うことができます。 私たちがその立場にあり、v1を持っている場合（現在はありません）、ケースバイケースで機能を取得し、その時点でメジャーバージョンに値するかどうかを判断するオプションがあります。 semverがないと、会話を始めることすらできません。これは、一部の人にとっては苛立たしいことだと思います。

単純化しすぎましたか？

このライブラリでは、クライアントアプリケーションの単純さ（頭を追う、修正を取得する）とメンテナの単純さ（頭で開発し、修正のためにロールフォワードする）のために下位互換性を強調します。 私は、メンテナの単純さよりもクライアントアプリケーションの単純さを重視しているので、アプリケーション開発者がこのライブラリの更新を簡単に受け取れるようにするリリースプロセスを採用したいと思っています。

私の意見を詳しく説明する価値があるかもしれません。 依存関係の管理は、開発のために変更を継続的に統合する方法と、リリースのためにビルドの再現性を確保する方法の2つの方法で考えています。 異なる（後方互換性のない）APIの名前が異なる限り、SemVerは必要ありません。 バージョンの固定により、このライブラリのような依存関係からの更新の受信が難しくなると思います。 バージョン管理がなければ、心配することは1つ少なくなります。 "> = 1.0.0"は、バージョン番号のセレモニーを理解して従うという偶発的な複雑さなしに、このライブラリがデフォルトで実行することです。

職場ではgoモジュールを使用していますが、アップストリームの変更も迅速に受け入れたいと考えています。 継続的インテグレーションを行うために、 https： //dependabot.com/などの内部ツールを使用してPRを作成し、アップストリームの変更ごとにバージョンを増やします。 規律あるメンテナが、追いつくためだけに、アプリケーション開発が直面しているバージョンチャーンの量に代わるものを提供できたと思います。

リリースの再現性のために、すべての依存関係のすべてのバージョンを保存しようとするのではなく、ビルドされたアプリケーションをテストバージョンで保存します。 つまり、リリースを繰り返したい場合は、すでにアーティファクトがあり、ソースを追跡する必要はありません。

goモジュールを使用すると、クライアントとメンテナの両方がv2 +の変更を管理する方法が文書化されます。 これらの期待に従うことは私の意見を無意味にし、それはこのライブラリの将来のメンテナと既存のアプリケーション開発者の両方にとって長期的には物事をより簡単にします。

semverがないと、会話を始めることすらできません。これは、一部の人にとっては苛立たしいことだと思います。

SemVerなしでこれらの会話を行うことができます（そしてそうすべきです）-gitタグの代わりに別のインポートパスを使用するだけです。

バージョニングのカーゴカルト

興味深い読み物、リンクしてくれてありがとう！

したがって、これらすべてのダウンストリームに最適と思われるアプローチは、モジュールgithub.com/streadway/amqpのマスターブランチにgo.modファイルを追加し、v2のv2で作業するやむを得ない理由がある場合です。 API：マスターから分岐し、 go.modをモジュールgithub.com/streadway/amqp/v2に更新し、準備ができたらv2.0.0としてリリースします。

それは正しいですか？

したがって、これらすべてのダウンストリームに最適と思われるアプローチは、モジュールgithub.com/streadway/amqpのマスターブランチにgo.modファイルを追加し、APIのv2で作業するやむを得ない理由がある場合です。マスターから分岐し、go.modをモジュールgithub.com/streadway/amqp/v2に更新し、準備ができたらv2.0.0としてリリースします。

ええ、それは正しいように聞こえます。 今日はタグなしでgo.modを追加できると思います。

ここでのすべての会話に基づいて、＃394を開きました。これは、 go.modを追加し、TravisCIを更新してGo1.11以降のモジュールモードでテストします。