@ junit-team / junit-committers 4.13リリースについて何か考えはありますか？ 残念ながら、私は日常の仕事で非常に忙しいので、4.13リリースを運転することはできませんが、確かに助けることができます。

いくつかの未解決の問題をMilestone4.13に開始点として関連付けましたが、マイルストーンにはコメントスレッドを含めることができないようです。そのため、スケジュールとどの機能をここに含めるかについて話し合うことができると思いました。

私がやりたいことの1つは、 Assert.assertThrows / expectThrowsをJupiterのAssertions.assertThrows揃えることです。 私は周りにいくつかの論争があったことを知っている木星は、私たちは、移行のシナリオを検討して削除すべきだと思うリリースされていることを、バックしながら、今はAssert.assertThrowsし、名前の変更expectThrowsにassertThrows 。 異議はありますか？

それらの1つを削除する最後の試みは＃1396でした

私は、合併についての議論の両側を見ることができますassertThrowsとexpectThrows 、私はプルは削除に反対しないように、 expectThrows・更新assertThrows復帰へのキャッチされた例外。 この問題の解決策を知らせるために、これらのメソッドを4.xに追加する元のプルに関係する人々に連絡することをお勧めします。 APIの方向性に関係なく、動揺する人もいると思いますが、それでも、自分の声が聞こえていることを全員に知ってもらうのは良いことだと思います。

その間、 assertThrows(Class<T> expectedType, Executable executable, String message)をJUnit4に移植するのは素晴らしいことです（https://github.com/junit-team/junit5/commit/ea67ca0を参照）

4.13リリースの進捗状況は？

@zjffduはい。 最近の作業についてはhttps://github.com/junit-team/junit4/pulse/monthlyを、提案されている残りの作業についてはhttps://github.com/junit-team/junit4/milestone/3を参照して

@kcooney
@marcphilipp
前回のリリース4.12からほぼ4年が経ちました。
より詳細なテストのために4.13-beta-1リリースバージョンをカットします。

私（私の組織は本当に）はTemporaryFolder （特に問題＃1223）で行われた作業を本当に使いたいので、JUnit4.13を入手することに本当に興味があります。 プロジェクトのフォーク（4.12）を取得し、 TemporaryFolder修正を厳選し、4.13が実際にリリースされるまでそこから生成されたJUnitアーティファクトを使用することを検討しています。 （フォークを使用するプロジェクトの少なくとも一部はパブリック/ OSSプロジェクトであるため、フォークから生成されたアーティファクトを公開する必要があります（私たちが所有するMavenグループ）からMavenCentralへ。 ただし、4.13をすぐに削減することを計画している場合は、お待ちください。 （JUnit 5に移行するための取り組みは進行中ですが、 TemporaryFolderまだ役に立ちません。）

考え？

バグ修正を活用する必要があったため、しばらくの間、4.13をそのまま構築して使用し、すべての変更を加えました。 これまでのところ問題は発生していません。

@cljohnsoが独自のバージョンのJUnitをMavenで公開すると、一部のユーザーにとって問題になる可能性があります。これは、JUnitの公式バージョンに依存している可能性があり、両方の依存関係があると、クラスパスでクラスが重複し、予期しない動作が発生するためです。

残念ながら、JUnitはボランティア（その多くはJUnit 5に取り組んでいます）によって保守されているため、リリースには予想よりも長い時間がかかりました。

準備を支援する1つの方法は、リリースノートを修正して確認することです。 多くのプルリクエストはそこで文書化されていませんでした（これらのバグを参照してください）。

4.13のブロッキングバグはここにあります。

4.13に割り当てられたすべての問題が解決されたようです。

@ junit-team / junit-committers 4.13をリリースする前に対処する必要のあるものは他にありますか？

@marcphilippこれらのクローズドプルリクエストは、リリースノートに記載されていない可能性があります： https ： utf8 =✓＆q = label％3A "needs + release + notes + update" +

リリースノートを完成させ始めました。 そうすることで、2つの新しいプルリクエストを作成しました：＃1551と＃1552。 少なくとも＃1552は4.13にあるはずです。

皆さんこんにちは、

このリリースのタイムラインは誰かあるのだろうかと思っていました。 私が取り入れたいと思っていた機能がいくつかあり、それをテーブルに入れるべきかどうか疑問に思っていました。

すべての作業に感謝します！

@johnterrill 4.13にこれ以上の新機能を追加する予定はないと思います（バグ修正のみ）

追加したいものがありましたら、お気軽に機能リクエストを追加してください。 そうは言っても、JUnitのほとんどすべての機能開発はjunit5リポジトリで行われています。

@kcooney 4.13にバグ修正のみが含まれている場合は、名前を4.12.1ます。 まだ進行中の作業はありますか？

これはバグ修正ではなく、注文などのいくつかの新機能もあります。 したがって、4.13は理にかなっていると思います。

リリースノートにはまだ5つのPRがありません。 明後日ドイツに戻ったとき、私は彼らの世話をします。 AFAIKこれが残っているすべてです。

@marcphilipp JUnit4.13の準備ができていると思います。 リリースノートを完成させました。

JUnit 4.13で＃1568をリリースしておくと便利ですが（メンテナの1人からのレビューが必要です）、必須ではありません。

4.13リリースのアップデートはありますか？ 新しいリリースが行われるのを見てとても興奮しています。 :)

@robinyqiu
彼らはJUnitの廃止を計画しており、4.13が最後のバージョンでなければならなかったことを覚えています。 103の未解決の問題といくつかの保留中のプル要求があるため、バージョンは開発を継続する必要があります。 1つの方法は、いくつかのリリース候補バージョンをカットすることです。バグとプルリクエストの数に関する統計で何が起こるかを確認します。

まだ4.13をリリースする予定だと思います（マージされた改善と修正の数が非常に多いため）。

申し訳ありませんが、考えを終える前に最後のコメントを送信してください。

しばらく時間がかかっていることをお詫びします。 元のJUnitメンテナは、JUnit 5のサポートで忙しいか、JUnitでの作業から一歩後退しました。 これらの理由から、4.xコード行の場合、4.13が最後のリリースになる可能性が高いと思います。

@ Tibor17 @kcooneyご回答ありがとうございます！ 4.13リリースがいつ行われるかについての大まかな見積もりはありますか？

@robinyqiu私は
@kcooneyコミュニティは、今後数週間または数か月のリリース計画を明確に提示する必要があると思います。

私は、世界中がJUnit4に長い間依存しているという事実のために、JUnit4はゼロの問題とゼロのプルリクエストでファイナライズされるべきであると今でも確信しています。
したがって、機能のリクエストを見つけた場合は、その可能性はJUnit5にあり、JUnit4にはないことを伝えて閉じてください。
私たちの問題を修正し、プルリクエストを受け入れる必要があります。 古いプルリクエストは、PRを作成した人とのコンセンサスに達していないため、クローズする必要があると私には思われます。

@ Tibor17修正する必要があると思われるバグがある場合、または受け入れる必要があるリクエストをプルする場合は、それらの問題にコメントを追加してください。 ある時点で、4.13のリリースを削減することを決定する必要があります（ほぼ4年前に4.12をリリースしました）。

JUnit4.xの基本的にバグ破産を申請することについてどう思うかわかりません。 私は確かにそのプロセスを通過する時間がありません。 おそらく、他のメンテナンス担当者の1人がそうしています。

@marcphilippリリース4.13をカットする時間はありますか？ @ kcooney 、 @ dsaff異議はありますか？

@kcooneyはい、2015年から2017年まではクローズする必要のある問題があると思います。 これが最初のステップになります。 それは明確な画像とユーザーに私たちが真剣にそれらを継続しないという合図を与えます。 残っている唯一の問題は、再調査し、それらだけに時間を費やす必要があります。 そして、私たちは再び手をきれいにし、最終的にプロジェクトを完了することができます。

リリース4.13をカットする時間はありますか？

はい、週末にできます。 最初に4.13-RC1ま​​たは4.13-beta-1を出荷する必要がありますか？

4.13-beta-1は良い考えです。 古いベータリリースの命名スキームを維持します。

4.13-beta-1に問題がない場合、その後4.13をどのくらい待つ必要がありますか？ 2週間？

リリースをカットすることに異論はありません。 RC1対ベータ1についての強い意見はありません。

4.13-beta-1が本日リリースされ、MavenCentralで利用できるようになりました。

ありがとう@marcphilipp ！

Hamcrestが新しいバージョンをリリースしようとしているよう

Hamcrestへの依存関係を新しいリリース用に更新できれば素晴らしいと思います。 これは実行可能でしょうか？

@BlueIceこれを私たちの注意を

JUnit4はまだJava5と互換性があるため、Java 7が必要なため、Hamcrest2.xにアップグレードできないと思います。

ただし、POMでHamcrest optionalに依存する必要があるかどうか疑問に思っています。 そのため、ユーザーはHamcrestを使用するかどうか、使用する場合はどのアーティファクトとバージョンを使用するかを意識的に選択する必要があります。

@tumbarumba @ junit-team / junit-committers WDYT？

こんにちは、ハムクレストのコミッターです。 現在、Hamcrestの2.1リリースを準備しています。 Hamcrestの依存関係を更新できれば素晴らしいと思います。 最近v2.1-rc3をリリースしました。 メジャーバージョン番号の増加にもかかわらず、このリリースは1.3（長い話）との下位互換性を意図しています。

注意すべき点の1つは、バージョンHamcrest 2.1で、jarのパッケージ化方法を変更したことです。 hamcrest-coreとhamcrest-libraryは、1つのアーティファクトhamcrest （例： hamcrest-2.1.jar ）にマージされました。 下位互換性のために、 hamcrest-coreおよびhamcrest-libraryアーティファクトの2.1バージョンをリリースしていますが、これらのjarは空であり、 hamcrest-2.1.jarへの推移的な依存関係を通じてアップグレードを簡素化できるように提供されています。

オプションの依存関係も機能します。 試したことはありませんが、 Assertions.assertThat(...)を使わなければ、依存関係はまったく必要ないと思いますか？ あなたが使用マッチャーを行う場合には、明示的にどちらかに応じて、宣言hamcrest-core-1.3.jarまたはhamcrest-2.1.jar働くだろう（私はかかわらず、これをテストしていませんが！）

私の個人的な好み：JUnit 4.13をhamcrest-2.1.jarに直接依存させる。 これは、ほとんどの人にとって最も驚くべきアップグレードパスではないと思います。

@タンバランバ
私は、Java Hamcrest 2.1を使用したいが、それは@marcphilippが述べたように、私はまさにためのJava 1.5の互換性のためのJUnitの中でそれを見たいという意味ではありません。
あなたが言ったことによると、 hamcrest-coreはhamcrestに伝統的に依存しています。ユーザーとして、私のPOMのdependencyManagementでより高いバージョンを使用することに問題はありません。 とにかく私はhamcrest-library:1.3を使用していて、バージョンを2.1変更することは私がしなければならないことであり、大したことではありません。 プロジェクトJUnit5はhamcrest:2.1について考えることができるかもしれませんが、それは別の話です。

ああ、私はJUnit4がJava5と互換性があるという点を見逃しました。もちろん、これはJUnit4.xが少なくとも直接ではなくHamcrest2.0以降に依存できないことを意味します。 JUnit 5は、サードパーティのマッチャーへの依存関係をすべて削除したため、Hamcrestから完全に独立しています。

1つのオプション：JUnit4.13はHamcrest1.3への依存関係を維持します。 Hamcrest 2.1の新機能を使用したい場合は、 hamcrest-core-2.1.jarへの依存関係を明示的に宣言できます。これにより、バージョンの競合解決プロセスがトリガーされ、ライブラリがアップグレードされます（最初に宣言されている場合）。

別のオプション：pom <optional>属性を使用します。 あまり経験がありません。 hamcrest-core-1.3.jarとhamcrest-2.1.jar両方にオプションの依存関係を宣言することは可能ですか？ その場合はどうなりますか？

@タンバランバ
JUnitのPOMでoptional依存関係hamcrest-2.1.jarを使用することは、ユーザーがそれを自分のPOMに継承できないことを意味します。 基本的に、それは推移的な依存関係ではなく、 hamcrest-2.1.jarをまったく宣言しないのと同じ効果になります。

これを数日間熟考した後、下位互換性のためにhamcrest-core:1.3への必須の依存関係を維持する必要があるという結論に達しました。 オプションにすることは、ほとんどのユーザーが別の依存関係を追加する必要があるため、良いことよりも害を及ぼします。

Hamcrest2.1に関するリリースノートにメモを追加できます。 さらに、JUnit 4.xで新しいバージョンを使用する方法と、HamcrestのWebサイトまたはWikiでさまざまなビルドツールを文書化することをお勧めします。 理想的には、JUnit4.13リリースノートからこのページにリンクできます。

@タンバランバWDYT？

@marcphilipp、あなたの結論に同意します。 私が今理解しているように、Java1.5へのJUnit4の依存関係は、Hamcrest 2.xを完全に除外し、私が見る限り、オプションの依存関係を使用することは機能しません。

ドキュメントに関しては、Hamcrestドキュメントを更新するためのプルリクエストを開いています（hamcrest / JavaHamcrest＃237を参照）。 それについてのフィードバックをいただければ幸いです。 Hamcrest 2.1のドキュメントは、 https： //tumbarumba.github.io/JavaHamcrest（特にHamcrest 1.xからのアップグレードに関するメモ）でプレビューできます。 実際のHamcrest2.1がリリースされるまで、そのプルリクエストをマージしません。

非推奨のクラスに関するいくつかの問題を修正するために、Hamcrest2.1の別のリリース候補をリリースしようとしています。 うまくいけば、これが最後のRCになります（フィードバックがない限り）。 hamcrest / JavaHamcrest＃224をチェックして、次のHamcrestリリースをフォローしてください。

4.13-beta-1がリリースされてから3週間が経ちました。 4.13の最終リリースを妨げるものはありますか？

@ijumahttps ：//github.com/junit-team/junit4/milestone/8に1つの問題がリストされています

＃1569を含める場合があります

＃1569とリリース4.13-beta-2を含めるべきだと思います。 それを反映するために、対応する新しいマイルストーンを作成しました。

beta-2 / GAのリリースをいつ期待できるかについてのニュースはありますか？ 私は4.13にとても興奮していて、実際にそれを使用することに熱心ですが、それはまだ「ベータ」ステータスを持っているので、私の日常の仕事では使用できません:-(

＃1586がマージされたので、数日中に4.13-beta-2をリリースします。

@ junit-team / junit-committers異議はありますか？

異議なし😊

4.13-beta-2がリリースされ、テストの準備が整いました。

4.13-beta-2から1か月以上が経過しており、私が知る限り、問題の報告はありません（＃1593を除く）。 今後数日で4.13をリリースすることを提案します。

@ junit-team / junit-committers異議はありますか？

ApacheKafkaには4.13-beta-2を問題なく使用しています。

@ijuma教えてくれてありがとう！

異議はありません。 私は仕事でそれを使用しています、そしてすべてがうまくいきます。

Googleで4.13を使用するプロセスを開始したところ、2つの警告（ビルドシステムではエラーとして扱われます）が発生し、2つのプルリクエストが送信されました。 4.13で多くのテストを実行し始めると、さらに多くの問題が発生する可能性があります

一週間くらい待つことはできますか？

または、4/13をターゲットにすることもできます;-)

@kcooneyあなたが言及した2つのPRは＃1596と＃1597であるというのは正しいですか？ 4/13は完璧なターゲットのように聞こえます:-)

それは良い検証のように聞こえるので、結果を待ちましょう。

おもしろい事実：4.12は12/4にリリースされました😉

@kcooneyあなたが言及した2つのPRは＃1596と＃1597であるというのは正しいですか？

はい。

MockitoのDefaultInternalRunnerにリグレッションが見られます。 何が起こっているのか理解するのに苦労していますが、問題は、テストが失敗したにもかかわらず、 testFinishedが呼び出されることです。 ただし、 ParentRunnerの履歴からを見つけることはできません。

4.13で回帰し、4.12で合格するテストは、 https： //github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/internal/runners/DefaultInternalRunnerTest.java#L42-L59です

@TimvdLippe RunListener.testFinished()のJavadocは次のように述べています。

「アトミックテストが終了したときに、テストが成功したか失敗したかに関係なく呼び出されます。」 4.12と4.13で異なる動作が見られる理由はわかりませんが、4.13で見られる動作は正しいように聞こえます。

JUnit 4.12との統合が壊れるのではないかと心配していますが、JUnit4.13で正しく動作するように動作を更新したいと思います。 私は明日解決策を見つけようとします。

Mockitoから＃1599に複製ケースを抽出することができました。 withBeforesの取り扱いに関係しているようです。

コードベースで4.13をテストしているので、＃1421がいくつかの問題を引き起こしています。

誰かが＃1421を元に戻すPRを提出する時間がありますか？

@panchenkoによって＃1602で行われました。

@kcooney別のベータリリースを行いましょうか。

@marcphilippあなた次第。 最近の変更は4.12の人々に影響を与えるべきではありません（4.13のプレリリースの人々のみ）。

私たちのコードベースでは、現在、 nullをFrameworkMethodコンストラクターに渡す多くの場所で作業しています🙄残念ながら、実際の問題を確認するのは困難です。

@kcooneyこれらの変更を

@marcphilipp返信が遅くなってすみません（休暇中です）。 現在、テストの2.9％がJUnit 4.13で失敗していますが、一部は不安定な失敗である可能性があります。 手動サンプルでは、​​4.13での変更による問題は示されていませんが、まだ多くのことを行う必要があります。

@kcooney心配ありません！ だから、見積もりはありませんよね？ 😉

@marcphilippこれまでのところ、残りの失敗は疑わしいことを行ったテストであるため、それらの4.13をブロックしません。 今夜はすべての失敗を調べます。

疑わしいことをしたために失敗したテストのいくつかの例：

サブクラスに基本クラスフィールドと同じ名前とタイプの@Ruleフィールドがあるテストがいくつかあります（これも@Rule注釈が付けられています）。 どうやら4.12ではサブクラスルールが基本クラスルールの代わりに実行されますが、4.13では両方が実行されます。 シャドウメンバーの働き方を変えたことを覚えています。 私が見ているのが意図的な変更であったかどうかは思い出せません。

また、JUnit 4.13が改善されたエラーメッセージを生成し、テストが特定のエラーメッセージをアサートしているという失敗も見られます。

（プルリクエスト番号を修正するために編集）

@ marcphilipp ＃1414で変更を加えた理由を思い出そうとしています

フィールドが基本クラスから同じフィールドをシャドウイングしないのは事実ですが、JUnit 4.xは、しばらくの間、シャドウイングするかのように処理しました。 私が取り組んでいる（ここでも大きな）コードベースには、サブクラスクラスの@Ruleフィールドがベースクラスのフィールドの動作を置き換えることを前提としたコードの例がたくさんあります。 この問題を回避するのはそれほど難しいことではありませんが（フィールドをメソッドに変更して、サブクラスがオーバーライドできるようにします）、そのプルの利点が既存のユーザーのコストを上回るかどうか疑問に思います。

下位互換性のために疑わしい動作ではありますが、それを元に戻して古いものを復元する必要があると思います。

@stefanbirkner WDYT？

同意します。 既存のテストを破ることを正当化する利点は見当たりません。

最終的に＃1414を元に戻す＃1605を作成しました。

別のベータリリースをリリースする必要があると思います。 @kcooney数日以内にそれを実行しますか、それとも4.13-beta-2で追加の問題を発見しましたか？

@marcphilipp最新の変更でパッチを適用しましたが、再実行を確認している間、パターンは表示されません（改善したエラーメッセージをアサートするテストを除く）。 私が見ている残りの問題は、悪いテストまたは不安定なテストだと思います。

申し訳ありませんが、これには時間がかかりましたが、これらの変更を元に戻してよかったです。

4.13-beta-3がリリースされ、テストの準備が整いました。

そのうちの1人がhttps://github.com/junit-team/junit4/pull/1608にマージできれば素晴らしいと思い

＃1609をご検討いただければ幸いです。

最近、JUnit4.12からJUnit4.13-beta-3にアップグレードしました。 それはうまく機能しています。

アップグレードした理由は、この修正が必要だったためです。
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

4.13.0 GAについて何か考えはありますか？

@sullis残りの主な問題は、推奨事項を修正することです。 ハムクレスト（＃1608を参照）。

ハムクレストチーム（別名私）は、＃1608に関して変更を加える予定はありません。 これは、4.13に他のブロッカーがないことを意味しますか？

ハムクレストチームが変更を加えるのを待っているという意味ではありませんでした。 私はhttps://github.com/junit-team/junit4/pull/1608#issuecomment-496492379を参照していました：

要約すると、誰かがHamcrestに関するすべての非推奨を確認し、「非推奨メッセージ」が、それ自体がすでに非推奨になっている、および/または使用できなくなったものを使用するようにユーザーに通知しないようにする必要があります。

水曜日からの「非推奨メッセージ」を担当しています。

水曜日からの「非推奨メッセージ」を担当しています。

水曜日の夜までに完了した場合は、 Spring Framework 5.2 GAに含めることができる可能性があります。これにより、このコミットます。

しかし...プレッシャーはありません。 Spring Framework5.2がJUnit4.13をサポートしていると公式に述べているのは、便利なだけです。 JUnit 4.13がリリースされた後も、JUnit4.13はSpring5.2で問題なく動作します。 😉

こんにちは@sbrannen 、私は始めました、しかし私は今夜それを終わらせません。 私は現在すべてのコメントを読んでいて、すべての詳細を理解しようとしています。

@stefanbirkner 、心配ありません！ 私が言ったように、それは「持っていれば良かった」でしょうが、確かにそれに対する要件はありません。 JUnit 4.13には、Spring Boot2.2によって正式に取り上げられる時間がまだある可能性があります。 😉

4.13.0 GAについて何か考えはありますか？

＃1609の解決策がないと、JUnit4.13の関連性はそれよりも低くなるリスクがあります。 JUnit 4.12のユーザーは、壊れていないコードの非推奨ではなく、バグ修正とJUnit5からのバックポートを待っています。

JUnit 4.13 GAのブロッカーはありますか？

何も見えません。 4.13-rc-1を公開して、最新の変更に関するフィードバックをさらに入手します。

JUnit4.13-rc-1がMavenCentralでテストできるようになりました。 問題が発生した場合はお知らせください。

4.13 betaとrcをテストし、私たちの大規模な組織で機能します👍

JUnit 4.13-rc1をテストしましたが、問題は発生しませんでした。

Jenkins用のStashPull RequestBuilderプラグインを使用してJUnit4.13-rc-1をテストしました。 予想どおり、ファイルごとに1回ExpectedExceptionを使用するファイルに対して非推奨がトリガーされました。

多くの場合、テストは例外の種類、メッセージ、および原因をチェックしていました。 一時変数がないように、すべてのチェックを1つの式に収めることができました。

SpotBugs、sb-contrib、find-sec-bugsを使用した新しいコードに関する警告や非推奨は表示されません。

唯一の小さな欠点は、Linux上のEclipse 2019-09でassertThatのカバレッジが黄色で表示されることです。 以前よりもはるかに優れています。 その上、誰もテスト自体のテストカバレッジを気にしません。

JUnit 4.13のステータスはどうなっていますか？

3週間が経過し、報告された問題は1つだけです： https ：

@kcooney @stefanbirkner見ていただけませんか？ 上記の問題は解決できると思います。

@marcphilipp長い遅延をお詫びします。 私は1年以上JUnitに取り組む時間があまりありませんでした。

そのバグについてコメントしました。 どうすれば修正できるかわかりません。

4.13の機能リクエストが1つありました。 ＃1637を参照

こんにちは、JUnit 4.13のステータスはどうなっていますか？

1637が解決され、別のRCをリリースします。

JUnit4.13-rc-2がMavenCentralでテストできるようになりました。 問題が発生した場合はお知らせください。

JUnit 4.13-rc2をテストしましたが、問題は発生しませんでした。 LGTM

同様に、JUnit4.13-rc-2は正しく機能しています。 新しい例外チェックを使用しています。

JUnit 4.13 GAのブロッカーはありますか？

@ kcooney ＃1637が解決されたので、4.13-rc-2で再テストしてください。

すべてのアップデート？

JUnit 4.13 GAのブロッカーはありますか？

返事が遅れて申し訳ありません; ここ数週間は忙しいです。

最新のJUnitの変更をコードに統合する時間がありませんでした
リポジトリ。 私は、の動作をカバーする私たちの側のテ​​ストを見ました
クラスがFixMethodOrderを使用する場合のランダム化、およびそれらはほぼ正確に見えます
私がそれを引っ張ったテストと同じです。 JUnitをブロックする理由がわかりません
その修正でさらに検証を行うことでリリースします。

q：JUnit 4.13 GAのブロッカーはありますか？

JUnit 4.13がリリースされました！ 🎊
https://twitter.com/junitteam/status/1212403812192964608