コンパイラの新しいバージョンに依存する変更を伴う元のリポジトリへのプルリクエストを処理する方法
フォークしたgithubプロジェクトがあります。元のリポジトリは、バージョン4.02.1より前のバージョンのOCaml用に作成されました。 4.02.1コンパイラは、レポを修正してコミットする予定のさまざまな非推奨の警告を表示します。変更を元のプロジェクトにプッシュする必要があるかどうかわかりません。
私の質問は、サードパーティ（私）のコードが、元の作成者/プロジェクトが使用しているものよりも新しいバージョンのライブラリまたはコンパイラを必要とする状況で、元のリポジトリとのコードの共有をどのように処理する必要があるかです。なんらかの説明なしに新しいコードを提供することは軽率なようであり、私は確かに元のリポジトリのビルドを壊したくありません。
このような状況はどのように処理されますか？
これが通常githubでどのように処理されるかを説明します。ただし、それはすべて単なるコードであるため、他の場所に関連しています。
私が実行しているような本当に気の利いたプロジェクトには、すべてが正常に機能していることを確認するためのテストがあります。
さらに、私が取り組んでいるようなwayのクールなプロジェクトには、ある種の 継続的インテグレーション があります。これは、外部の独立したシステムが独自にテストを実行する方法があることを意味します。 githubは、変更がコミットされたことを独立したシステムに通知するgitcommitフックの既定のセットを使用するようにプロジェクトを調整します。
通常、継続的インテグレーションシステムに提供できる指示があり、システムの構築に役立ちます。具体的には、これらの指示または構成は、テストするOCamlのバージョンを指定する場合があります。
これらすべてが整った状態で、「プルリクエスト」を送信すると、githubは継続的インテグレーションシステムを開始するgitフックを実行し、チェックのステータスを利用できるようにします。 Githubはそれに気づきます（フックは缶詰で、ci用にカスタム化されているため、どこを見ればよいかがわかります）。そして、コードをマージしても安全かどうかを潜在的な所有者に警告します。 継続的インテグレーションがなくても、githubはマージの競合がないことを確認するために、サイドにマージを実行します。
OK。しかし、あまり洗練されていないプロジェクトで作業しているとしましょう。これはgitなので、それもかっこいいので、それだけで役に立ちます。
ここでできることは、ブランチを作成し、そのブランチへの変更を制限することです。次に、そのブランチからのプルを要求します。所有者はおそらく、変更を同じ名前のブランチにマージしてから試してみるでしょう。問題がなければ、その人はブランチを「メイン」ブランチにマージします。
実際、githubや派手なものを使用しているかどうかに関係なく、別のプロジェクトからの変更のためにブランチで作業することは常に良いことです。参照 git flow
他の変更と何ら変わりはありません。かなりの量の作業である場合は、最初にメーリングリストで実行してください。誰かがすでにそれに取り組んでいる可能性があります。些細な作業の場合は、それを実行して、明確な説明を付けてプルリクエストを送信してください。発生する最悪の事態は、拒否されることです。
非推奨はさまざまな理由で行われ、多くの場合、変更は古い言語バージョンとの下位互換性があります。可能であればそうするようにしてください。たとえば、識別子のISO-latin1文字は、4.02の非推奨警告に追加されました。古いバージョンでは、ISO-latin1文字なしで識別子をコンパイルできます。