バグが最新バージョンのパッケージ（ベータ版または不安定版）で修正された場合、次のメジャーバージョンがリリースされる前に安定する可能性がありますか？深刻な程度やそれと似た場合でなければそうではないようです。
実際には、2年または3年の最新バージョンで作業している開発者に役立ちますか？バグの報告にできるだけ多くの支援をしたいと思いますが、このために仮想マシンにSidインストールを設定することで、安定したバージョンのバグを報告する前に再現を試みることができますが、バグがまだ存在していても、新しいバージョンでは開発者が実際にStableについて報告されていますバグに多くの注意を払いますか？
この問題に関して言葉で表現できない追加の、あいまいな質問がたくさんあると思います。しかし、基本的にいくつかの開発者を悩ませるか、古いパッケージについて報告することができる場合は、コメントを聞きたいと思います。エラーは実際に役立ちます。
答え1
まず明確にすると、リリース（バイナリ）パッケージとソースソースパッケージの間に違いがあります。一部ディストロテスト、不安定、安定などでリポジトリを取り外します。開発者また、「stable」、「unstable」、「nightly」などのバージョンを保持します。これらは異なる（しかし、バージョン番号は一致します）。
また、ここで「ソースパッケージ」は配布パッケージを意味しません-src。ディストリビューションとは無関係に配布されるソースソースを意味します。つまり、これは通常直接使用しないパッケージです。ディストリビューションでは、このパッケージをバイナリ（および-src）形式で再パッケージ化します。
たとえば、私はfoobar;現在安定したソースコードパッケージはであり1.2.4、現在不安定なソースコードパッケージはです1.2.5。 （私ではない）Debianはこれを配布用にパッケージ化します。現在安定したリポジトリは1.2.3、現在のテストリポジトリはです1.2.5。私（元の開発者）いいえ Debian パッケージまたはどのソースバージョンがどの repo パッケージにあるかを担当します。私は展開用のバイナリバージョンをコンパイルしたりパッケージ化したりしません。ちょうど元のソースを維持している。
これらのエラーレポートも別々です。私は、元の開発者としてリリースパッケージに報告されたバグを読み、応答することも、応答しないこともあります。そうでない場合は、問題に注意を払う必要があり、配布パッケージは元のソースに関するレポートを送信します。
バグが最新バージョンのパッケージ（ベータ版または不安定版）で修正された場合、次のメジャーバージョンがリリースされる前に安定する可能性がありますか？
修正はバックポートされることはほとんどありません。つまり、安定リリースパッケージが 1.2.3 で 1.2.5 に対する修正があることがわかっている場合、次の安定リリースが 1.2.5 リカバリでない限り、その修正は含まれません。つまり、ディストリビューションが次の安定バージョンに1.2.4をリリースする場合、1.2.5の修正はディストリビューションにバックポートされないため、バグはまだ存在します。
ソースコードに関連するバグ（バイナリパッケージのWRT、時にはそうではないかもしれません）は、元の開発者が新しいバージョンのソースコードを修正し、それをリリースパッケージの対応するバージョンにマージする必要があります。ディストリビューションで独自にパッチを当ててバージョンにサフィックスを追加して表示する場合があるため、いくつかの例外があります (例:) ソースの1.2.4-1後続バージョンに修正がある場合にはそうではないと思います。
実際には、2年または3年の最新バージョンで作業している開発者に役立ちますか？
これはバグを修正するかどうかによって異なります。バージョン管理のポイントは固定されていることです。バージョン1.2.3がリリースされると、何が起こっても変更できません。 1.2.3で問題を修正すると、次のバージョンに修正が表示されます。長年にわたって中断された場合、バージョンはおそらく1.2.6などです。
したがって、最新バージョンのソースコードで修正されたことがわかっている場合は、元の開発者に報告する必要はありません。 しかし、現在のディストリビューションで使用されている安定したバージョンでバグがまだ報告されていない場合（ソースとパッケージについて報告されているバグが異なることに注意してください）、それを報告し、それ以降のバージョンのバグが報告されていることを示す必要があります。源泉。繰り返しますが、配布パッケージやバグレポートを担当する人は元の開発者とは異なることに注意してください。したがって、私が問題を解決したとしても、ディストリビューションの包装業者はそれを知らないか気にしないかもしれません。問題を報告すれば、引き続き情報を得ることができますが、彼らに与える（私ではありません）、あなたは明らかに彼らの注意を引いた。これは彼らが安定したパッケージをアップグレードすることを奨励するかもしれません（他のディストリビューションはそれに異なる基準を使用します）。
答え2
まず、バグ報告は一般的に良い考えです。それはフリーソフトウェアの多くのことのように感謝していますが、言葉です。
質問した内容を順番に回答したい場合は、
バグが最新バージョンのパッケージ（ベータ版または不安定版）で修正された場合、次のメジャーバージョンがリリースされる前に安定する可能性がありますか？
おそらくそうではありません。通常、修正はセキュリティの目的でのみ安定したリリースでバックポートされます。
実際には、2年または3年の最新バージョンで作業している開発者に役立ちますか？
安定したバージョンでバグを発見した場合、最初にすべきことは、現在のバージョンのソフトウェアまたは少なくとも最新のバージョンでバグを再現することです。通常、これは不安定なリリースで使用できるため、不安定なバージョンを安定したバージョンにバックポートしたり、不安定なシステムでテストしたりできます。不安定なビルドでバグが再現される場合は、私は通常、プロジェクトメーリングリストに他の人がバグを再現できるかどうかを尋ねます。時にはバグだけを報告することもあります。
不安定なバージョンが最新バージョンであっても、開発バージョンではバグが修正される可能性があるため、現在の開発バージョンのソフトウェア（通常はソフトウェアストアでのみ利用可能）をテストしない限り、このバグはまだ修正されていないことを確認してください。しかし、私は完全に最先端のコードをテストすることを気にしないことがよくあります。部分的には、コードがまだパッケージ化されていないため、パッケージ化されたソフトウェアを使用することを好みます。しかし、YMMV。
最新バージョンのソフトウェアでバグが修正された場合、通常はこれを報告しません。理論的にはこれは可能ですが、上流の開発者は間違いなく気にしません。AMDソフトウェアのDebianパッケージも気にしません。
最後に、次のように書きます。
しかし、新しいリリースでバグが続く場合でも、開発者は実際に安定リリースについて報告されたバグに注意を払うのでしょうか？
これが何を意味するのか分かりません。最新バージョンにバグがある場合は、最新バージョンについてバグを報告してください。安定したリリースについて報告されるのはなぜですか？