@junit-team/junit-committers 对 4.13 版本有什么想法吗？ 不幸的是，我的日常工作很忙，所以我无法发布 4.13 版本，但我当然可以提供帮助。

我已经将一些未解决的问题与里程碑 4.13 关联起来作为起点，但似乎里程碑不能有评论线程，所以我想我们可以讨论调度以及应在此处包含哪些功能

我想做的一件事是将Assert.assertThrows / expectThrows与木星的Assertions.assertThrows对齐。 我知道不久前对此存在一些争议，但现在 Jupiter 已经发布，我认为我们应该考虑迁移方案并删除Assert.assertThrows并将expectThrows重命名assertThrows 。 有异议吗？

最后一次尝试删除其中一个是 #1396

我可以看到关于合并assertThrows和expectThrows的争论的双方，所以我不会反对删除expectThrows和更新assertThrows的拉取返回捕获的异常。 我建议联系参与将这些方法添加到 4.x 的原始 pull 的人员，告知他们此问题的解决方案。 我意识到无论我们决定采用 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
@马克菲利普
距离上次 4.12 版本已经过去了将近 4 年。
剪切 4.13-beta-1 发行版以进行更深入的测试。

我（我的组织，真的）真的很想使用为TemporaryFolder （特别是问题 #1223）所做的工作，所以我真的很想获得 JUnit 4.13。 我们正在考虑对项目（在 4.12 版）进行分叉，挑选TemporaryFolder修复程序，并使用从中生成的 JUnit 工件，直到 4.13 版实际发布。 （还没有评估这有多健全/疯狂。）因为至少我们将使用分叉的一些项目是公共/OSS 项目，从分叉产生的工件将需要发布（在一个我们拥有的 Maven 组）到 Maven Central。 但是，如果您打算很快削减 4.13，我们可以等待。 （我们确实正在努力迁移到 JUnit 5，但这对我们TemporaryFolder还没有帮助。）

想法？

我们已经构建并使用了 4.13 及其所有更改，一段时间以来，因为我们需要利用错误修复。 目前没看到有什么问题。

@cljohnso在 Maven 中发布您自己的 JUnit 版本可能

不幸的是，JUnit 是由志愿者（其中许多人在 JUnit 5 上工作）维护的，所以 relesses 花费的时间比预期的要长。

帮助我们做好准备的一种方法是修复和查看发行说明。 那里没有记录许多拉取请求（请参阅这些错误）。

4.13 的阻塞错误在这里。

看起来分配给 4.13 的所有问题都已解决。

@junit-team/junit-committers 在发布 4.13 之前还有什么需要解决的吗？

@marcphilipp这些关闭的拉取请求可能没有记录在发行说明中： https : utf8 = ✓&q=label%3A"needs+release+notes+update"+

我开始完成发行说明。 为此，我创建了两个新的拉取请求：#1551 和 #1552。 至少#1552 应该在 4.13 中。

大家好，

我想知道是否有人有此版本的时间表。 我希望加入一些功能，并想知道我们是否应该将其列入表格。

感谢您的工作！

@johnterrill我不认为我们计划在 4.13 中添加更多新功能（只是错误修复）

如果您想添加某些内容，请随时添加功能请求。 话虽如此，几乎所有 JUnit 的功能开发都在 junit5 存储库中进行。

@kcooney如果4.13仅包含错误修复，请将其重命名为4.12.1 。 是否还有正在进行的工作？

这不仅仅是错误修复，还有一些新功能，例如订购。 因此，我认为 4.13 是有道理的。

发行说明中仍然缺少 5 个 PR。 后天回到德国的时候我会照顾他们。 AFAIK 这就是剩下的全部了。

@marcphilipp我认为我们已经为 JUnit 4.13 做好了准备。 我完成了发行说明。

将#1568 与 JUnit 4.13 一起发布会很好（需要一位维护者进行审查），但这不是必需的。

4.13 版本有更新吗？ 我很高兴看到新版本的发布。 :)

@robinyqiu
我记得他们计划停止使用 JUnit，而 4.13 必须是最后一个版本。 由于有 103 个未解决的问题和几个未决的拉取请求，这些版本应该继续开发。 一种方法是削减几个发布候选版本，我们将看到关于错误和拉取请求数量的统计数据会发生什么。

我相信我们仍然计划发布 4.13（因为已经合并了大量的改进和修复）。

对不起，在我完成我的想法之前提交了最后一条评论。

很抱歉这需要一段时间。 最初的 JUnit 维护人员要么忙于支持 JUnit 5，要么已经退出 JUnit 的工作。 由于这些原因，我认为 4.13 很可能是 4.x 代码行的最后一个版本。

@Tibor17 @kcooney感谢您的回复！ 你对 4.13 的发布时间有一个粗略的估计吗？

@robinyqiu我不是提交者，而是长期的贡献者。
@kcooney我认为社区应该清楚地展示接下来几周或几个月的发布计划。

我仍然相信 JUnit4 应该以零问题和零拉取请求最终确定，因为全世界都将长期依赖 JUnit4。
因此，如果您看到任何功能请求，请关闭它们，说它的可能性将在 JUnit5 中，而在 JUnit4 中不再存在。
必须修复我们的问题并接受拉取请求。 在我看来，旧的拉取请求我们还没有与创建 PR 的人达成共识，因此应该关闭它们。

@Tibor17如果有任何您认为必须修复的错误或应该接受的拉取请求，请为这些问题添加评论。 在某个时候，我们需要决定为 4.13 发布一个版本（我们大约在四年前发布了 4.12）。

我不确定我对 JUnit 4.x 本质上提交错误破产的感觉如何。 我当然没有时间经历那个过程。 也许其他维护者之一这样做了。

@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 与 beta-1 没有强烈的看法。

4.13-beta-1 已于今天发布，我现在可以在 Maven Central 上使用。

谢谢@marcphilipp ！

看起来Hamcrest即将发布一个新版本（参见 hamcrest/JavaHamcrest#224）。 候选版本已经可用 (https://github.com/hamcrest/JavaHamcrest/releases)。

如果可以为新版本更新对 Hamcrest 的依赖，那就太好了。 这可行吗？

@BlueIce感谢您引起我们的注意！

由于 JUnit 4 仍然与 Java 5 兼容，我认为我们不能升级到 Hamcrest 2.x，因为它需要 Java 7。

不过，我想知道我们是否应该在 POM 中依赖 Hamcrest optional 。 这将迫使用户有意识地选择是否使用 Hamcrest，如果使用，选择哪个工件和版本。

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

嗨，这里是 Hamcrest 提交者。 我目前正在准备 Hamcrest 的 2.1 版本。 如果可以更新 Hamcrest 依赖项，那就太棒了。 我最近发布了 v2.1-rc3。 尽管主要版本号有所增加，但此版本旨在向后兼容 1.3（长话短说）。

需要注意的一件事：在版本 Hamcrest 2.1 中，我们更改了 jar 的打包方式。 hamcrest-core和hamcrest-library已合并为一个工件： 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 。 我认为这对大多数人来说是最不令人惊讶的升级路径。

@tumbarumba
我想使用 Java Hamcrest 2.1 但这并不意味着我想在 JUnit 中看到它，正是因为@marcphilipp提到的 Java 1.5 的兼容性原因。
根据您提到的hamcrest-core依赖于hamcrest ，作为用户在我的 POM 的dependencyManagement中使用更高版本对我来说没有问题。 无论如何，我正在使用hamcrest-library:1.3并将版本更改为2.1是我必须做的，没什么大不了的。 也许JUnit5可以考虑hamcrest:2.1但那是另一回事了。

啊，我忽略了 JUnit 4 与 Java 5 兼容的观点。当然，这意味着 JUnit 4.x 不能依赖于 Hamcrest 2.0 或更高版本，至少不能直接依赖。 JUnit 5 移除了对第三方匹配器的所有依赖，因此完全独立于 Hamcrest

一种选择：JUnit 4.13 保持对 Hamcrest 1.3 的依赖。 如果有人想使用 Hamcrest 2.1 的新特性，他们可以明确声明对hamcrest-core-2.1.jar的依赖，这将触发版本冲突解决过程，并升级库（只要先声明）。

另一种选择：使用 pom <optional>属性。 我对此没有太多经验。 是否可以声明对hamcrest-core-1.3.jar和hamcrest-2.1.jar的可选依赖项。 在这种情况下会发生什么？

@tumbarumba
在 JUnit 的 POM 中使用optional依赖项hamcrest-2.1.jar意味着用户无法将其继承到他的 POM 中。 基本上，它不会是传递依赖，这与根本不声明hamcrest-2.1.jar效果相同。

经过几天的思考，我得出的结论是，为了向后兼容，我们应该保持对hamcrest-core:1.3的强制依赖。 使其成为可选的弊大于利，因为它需要大多数用户添加另一个依赖项。

我们可以在提到 Hamcrest 2.1 的发行说明中添加一个说明。 此外，我认为最好在 Hamcrest 的网站或 wiki 上记录如何将新版本与 JUnit 4.x 和不同的构建工具一起使用。 理想情况下，我们可以从 JUnit 4.13 发行说明链接到此页面。

@tumbarumba WDYT？

我同意你的结论，@marcphilipp。 正如我现在所了解的那样，JUnit 4 对 Java 1.5 的依赖完全排除了 Hamcrest 2.x，据我所知，使用可选的依赖是行不通的。

关于文档，我打开了一个拉取请求来更新 Hamcrest 文档（参见 hamcrest/JavaHamcrest#237）。 我会很感激任何反馈。 Hamcrest 2.1 文档可以在https://tumbarumba.github.io/JavaHamcrest预览（特别是关于从 Hamcrest 1.x 升级的说明）。 在真正的 Hamcrest 2.1 发布之前，我不会合并那个拉取请求。

我即将发布 Hamcrest 2.1 的另一个候选版本，以解决不推荐使用的类的一些问题。 希望这将是最后一次 RC（除非有更多反馈）。 检查 hamcrest/JavaHamcrest#224 以了解下一个 Hamcrest 版本。

自 4.13-beta-1 发布以来已经过去了 3 周。 有什么阻止最终 4.13 版本的吗？

@ijuma https://github.com/junit-team/junit4/milestone/8列出了一个问题

我们可能包括#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 发布以来已经一个多月了，据我所知，没有任何问题的报告（#1593 除外）。 我建议我们在未来几天发布 4.13。

@junit-team/junit-committers 有任何异议吗？

我们一直在为 Apache Kafka 使用 4.13-beta-2，没有任何问题。

@ijuma感谢您让我们知道！

没有异议。 我在工作中使用它，一切正常。

我刚刚开始在 Google 使用 4.13 的过程，遇到了两个警告（我们的构建系统将其视为错误）并发出了两个拉取请求。 当我开始在 4.13 下运行大量测试时，我可能会遇到更多问题

我们可以等一个星期左右吗？

或者，我们可以针对 4/13 ;-)

@kcooney你提到的两个 PR 是 #1596 和 #1597，我说得对吗？ 4/13 听起来是个完美的目标 :-)

这听起来像是一个很好的验证，所以让我们等待结果。

有趣的事实：4.12 已于 12/4 发布😉

@kcooney你提到的两个 PR 是 #1596 和 #1597，我说得对吗？

是的。

我在 Mockito 中看到DefaultInternalRunner的回归。 很难弄清楚发生了什么，但问题是即使测试失败也会调用testFinished 。 但是，从ParentRunner 的历史来看，我找不到任何明显的问题。

在 4.13 上回归并在 4.12 上通过的测试是https://github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/Default5RunnerLwillInts.java -继续调试，但任何指针将不胜感激 :smile:

@TimvdLippe RunListener.testFinished()的 Javadoc 指出：

“在原子测试完成时调用，无论测试成功还是失败。” 我无法解释为什么您在 4.12 和 4.13 之间看到不同的行为，但您在 4.13 中看到的行为听起来是正确的。

我想更新行为，以便它与 JUnit 4.13 一起正常工作，尽管我担心我们可能会破坏我们的 JUnit 4.12 集成。 明天我会想办法解决的。

我能够将 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？

我同意。 我没有看到任何可以证明打破现有测试的优势。

我创建了 #1605，它最终恢复了 #1414。

我认为我们应该发布另一个测试版。 @kcooney我是在接下来的几天内这样做还是您发现了 4.13-beta-2 的其他问题？

@marcphilipp我修补了最新的更改，虽然我仍在查看重新运行，但我没有看到任何模式（除了对我们改进的错误消息进行断言的测试）。 我认为我看到的其余问题是糟糕的或不稳定的测试。

抱歉这花了这么长时间，但我很高兴我们恢复了这些更改！

4.13-beta-3 已发布并准备进行测试。

如果你们中的一个人可以在https://github.com/junit-team/junit4/pull/1608 中合并，那就太好了

如果您考虑#1609，我也将不胜感激。

我最近从 JUnit 4.12 升级到 JUnit 4.13-beta-3。 它工作得很好。

我升级的原因是因为我需要这个修复：
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

对 4.13.0 GA 有什么想法吗？

@sullis剩下的主要问题是修复建议。 火腿（见#1608）。

Hamcrest 团队（又名我）不打算对 #1608 进行任何更改。 这是否意味着 4.13 没有其他阻止程序？

我并不是说我们在等待 Hamcrest 团队做出改变。 我指的是https://github.com/junit-team/junit4/pull/1608#issuecomment -496492379：

总之，有人需要审查有关 Hamcrest 的所有弃用情况，并确保“弃用消息”不会建议用户使用本身已弃用和/或不再可用的内容。

从周三开始，我将处理“弃用消息”。

从周三开始，我将处理“弃用消息”。

如果你在周三晚上完成它，我也许可以将它包含在Spring Framework 5.2 GA 中，从而允许我恢复这个提交https://github.com/spring-projects/spring-framework/commit/665e8aa51c11992909134d3ad5eebca6c94aa877。

但是……没有压力。 官方声明 Spring Framework 5.2 支持 JUnit 4.13 只是一个很好的例子。 一旦 JUnit 4.13 发布，JUnit 4.13 仍然可以很好地与 Spring 5.2 配合使用。 😉

嗨@sbrannen ，我开始了，但今晚我没有完成。 我目前正在阅读所有评论并尝试了解所有细节。

@stefanbirkner ，不用担心！ 就像我说的那样，这本来是“很好的”，但肯定没有要求。 JUnit 4.13 仍有可能被 Spring Boot 2.2 正式采用。 😉

关于 4.13.0 GA 的任何想法？

如果没有针对 #1609 的一些解决方案，JUnit 4.13 的相关性就会降低。 JUnit 4.12 的用户正在等待 JUnit 5 的错误修正和可能的一些向后移植，而不是等待未损坏的代码的弃用。

JUnit 4.13 GA 是否有任何阻止程序？

我没有看到。 我将发布 4.13-rc-1 以获取有关最新更改的更多反馈。

JUnit 4.13-rc-1 现在可在 Maven Central 上进行测试！ 如果您遇到任何问题，请告诉我们。

测试了 4.13 beta和rc并在我们的大型组织中为我们工作👍

我测试了 JUnit 4.13-rc1，没有遇到任何问题。

我使用适用于 Jenkins 的 Stash Pull Request Builder 插件测试了 JUnit 4.13-rc-1。 正如预期的那样，对每个文件使用ExpectedException文件触发了弃用。

在许多情况下，测试会检查异常类型、消息和原因。 我能够将所有检查放入一个表达式中以避免使用临时变量。

我没有收到关于带有 SpotBugs、sb-contrib 和 find-sec-bugs 的新代码的任何警告或弃用。

唯一的小缺陷是assertThat的覆盖范围在 Linux 上的 Eclipse 2019-09 中显示为黄色。 还是比以前好多了。 此外，没有人关心测试本身的测试覆盖率。

JUnit 4.13 的状态是什么？

现在已经三个星期了，只报告了一个问题： https :

@kcooney @stefanbirkner你能看一下吗？ 我认为我们可以关闭上述问题。

@marcphilipp抱歉耽误了这么久。 一年多来，我没有太多时间在 JUnit 上工作。

我评论了那个错误。 我不明白我们如何解决它。

我确实有 4.13 的一项功能请求。 见#1637

嗨，JUnit 4.13 的状态如何？

1637 已解决，我将发布另一个 RC。

JUnit 4.13-rc-2 现在可在 Maven Central 上进行测试！ 如果您遇到任何问题，请告诉我们。

我测试了 JUnit 4.13-rc2，没有遇到任何问题。 LGTM

同样，JUnit 4.13-rc-2 对我来说工作正常。 我正在使用新的异常检查。

JUnit 4.13 GA 是否有任何阻止程序？

@kcooney既然#1637 已解决，您能否用 4.13-rc-2 重新测试？

任何更新？

JUnit 4.13 GA 是否有任何阻止程序？

这么晚才回复很抱歉; 最近几周事情一直很忙。

我没有时间将最新的 JUnit 更改集成到我们的代码中
存储库。 我确实看过我们这边的测试，这些测试涵盖了
当类使用 FixMethodOrder 时随机化，它们看起来几乎完全一样
和测试一样，我把它拉了。 我没有看到阻止 JUnit 的原因
发布对该修复程序进行更多验证。

问：JUnit 4.13 GA 是否有任何阻止程序？

JUnit 4.13 发布了！ 🎊
https://twitter.com/junitteam/status/1212403812192964608