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 <[email protected]> wrote: > Thanks for the reply. See my feedback below > > On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana <[email protected]> > 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 < > [email protected] > > > > > 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 > > > > > >
