Thanks Robert. To emphasis on the goal, we'd like to get a GA release of surefire that fully supports JUnit 5 (including the use of the vintage engine) and we'd like to see if it would be possible to backport the two fixes I've mentioned. If there is an appetite for that, we're happy to help and test snapshos and I believe the JUnit team would also be willing to help as they have contributed numerous PRs in the past.
If a fix cannot be enabled by default in a maintenance release, we'd like to understand why and how we can mitigate this for our users. Thank you, S. On Mon, Feb 25, 2019 at 3:01 PM Robert Scholte <rfscho...@apache.org> wrote: > Let me guide this discussion a bit, because I see tends to go to the > negative side, whereas I'd like to see this as an open and fair discussion. > > It is not up to us to decide what any company/organization policy is > regarding versions. > Putting yourself in the position of Pivotal it makes sense to rely only > on > GA versions. > There must be a reason why Surefire is released with milestones: things > might break and maybe for valid reasons. > We should prevent the situation where contributors see a milestone and > "kindly" update it because there's a non-milestone version available, > whereas one of the next surefire milestone would decide to break > backwards > compatibility. So this is not just about looking back and knowing that > the > latest milestone still works like 2.22.1, but also about the upcoming > versions! > > To me the question of Stephane is fair: is it possible to backport > SUREFIRE-1614 and SUREFIRE-1546? In other words: do these fixes depend on > 3.0.0 specific changes or not? If so, then there's no reason to continue. > Otherwise is it possible (with or without help of Pivotal or other > volunteers) to provide patches which can be applied and released? > > Stephane could have picked this up on his own, bypassing the main > maintainers of surefire, but he didn't. Instead he's asking for > cooperation. > > So try to keep the discussion polite and let's work together toward > solutions. > > thanks, > Robert > > On Mon, 25 Feb 2019 12:53:04 +0100, Tibor Digana <tibordig...@apache.org> > > wrote: > > > Sorry, in normal circumstances projects release BOM with > > dependencyManagement but not the pluginManagement. > > We did not break current users and so we split the entire work into > > multiple stages. The naming convention really is not a problem as you can > > see and Stephane confirmed it. > > So we made welcome compromises on our side in ASF and now your steps in > > Spring should be to make compromise in your internal policies. > > > > Cheers > > Tibor > > > > On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll > > <stephane.nic...@gmail.com> > > wrote: > > > >> Thanks for the reply. See my feedback below > >> > >> On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana <tibordig...@apache.org> > >> wrote: > >> > >> > Stephane, the problem is with Spring upgrade policy as I have > >> understood. > >> > > >> > What about releasing RC4 for you? > >> > > >> > >> It does not matter how you call it. We don't want to be in a position > >> where > >> our users get plugin management for a given version of surefire that: > >> > >> 1. is not GA > >> 2. subsequent milestone/RC/release will break backward compatibility > >> > >> > >> > >> > Do you really need to have SUREFIRE-1546 done? We do not want to > >> enable > >> it > >> > implicitly as it is done in master right now, and therefore M4 needs > >> to > >> > take more time to enable this feature via configuration. > >> > > >> > >> I think we do. > >> > >> A minor release of Spring Boot cannot require users to write their tests > >> using the JUnit 5 API as it would be a breaking change for every test > >> they’ve written using JUnit 4. On the other hand, we know that users > >> want > >> to be able to use JUnit 5 and we’re holding them back at the moment. > >> > >> The way the JUnit team has dealt with the migration is the use of the > >> vintage engine that we would provide by default. Users that have > >> migrated > >> their tests can exclude the vintage engine while users that are in the > >> process of migrating can benefit from a setup where they can start > >> migrating while keeping some of their tests unchanged. > >> > >> We need surefire to support that scenario and the 2.x line does not. > >> > >> > >> > > >> > I see that the policy is against itself. If you concentrate only on > >> > policies with project dependencies, you won't break anything. > >> > We made a big investment (SUREFIRE-1614, ...) to not to break current > >> > users. So please let us continue our work and let you and yourself use > >> > 3.0.0-M3 and continue whatever it means with Spring policies.Our > plan > >> is > >> to > >> > not to break backwards compatibility till 3.0.0-M5. > >> > > >> > >> As I've indicated, we cannot upgrade to a version and then be stuck on > >> milestones because a later one introduces backward incompatible changes. > >> > >> > >> > > >> > There is reason that you use Surefire in your project and provide us > >> with > >> > feedback. We can always release milestones or RCs (which don't have > >> > different meaning for me). > >> > > >> > >> To be fair, we use surefire because Spring Boot supports Maven (as it > >> should). JUnit 5 was released 18 months ago so a full support in the > >> current GA would be very much appreciated. > >> > >> > >> > >> > > >> > Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from > >> > > >> > > >> > https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/ > >> > (plugin repository) and let us know with the feedback. > >> > > >> > Is RC4 legal for your policies? > >> > > >> > >> No it isn't. The name is not the problem by the way as I've hopefully > >> indicated above. > >> > >> Thanks, > >> S. > >> > >> > >> > >> > >> > > >> > Cheers > >> > Tibor > >> > > >> > > >> > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll < > >> stephane.nic...@gmail.com > >> > > > >> > wrote: > >> > > >> > > Hi everyone, > >> > > > >> > > It's great to see the progress on Surefire 3.0 and I wanted to reach > >> out > >> > to > >> > > discuss a practicable problem with the 2.x line. There are a > number > >> of > >> > > fixes for JUnit 5 that are only available in the 3.x line that > >> isn't GA > >> > > yet. [1][2] > >> > > > >> > > Putting my Spring Boot hat for a min, this actually prevents us from > >> > > upgrading our test support to JUnit 5: our plan is to offer maximum > >> > > flexibility by providing the vintage engine (so that users can keep > >> their > >> > > tests and migrate at their own pace). > >> > > > >> > > We can't upgrade to a milestone as our upgrade policy prevents that > >> > > (regardless of how stable this is and especially since backward > >> > > incompatible changes have been pushed to the latest milestone). So > >> we're > >> > > kind of stuck. > >> > > > >> > > Would there be an appetite to backport those fixes and release a > >> 2.22.2? > >> > > > >> > > Thanks, > >> > > S. > >> > > > >> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614 > >> > > [2] > >> > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546 > >> > > > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
