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
> >
>
