Well, we had found that we couldn't get all the required variations of JUnit 5 working in Maven without the M release, so we had to upgrade. We have tested our scenarios with M7, including test suites and mixed Junit4 and JUnit5 tests, and we're not seeing any problems (including one scenario that produced the BufferOverflow exception with M6).
The thing is, if you're not confident enough with it to produce a non-M release, that makes us a little nervous also. The scenarios we've tested are a tiny fraction of the services that will be using this. I don't expect to see any unexpected problems, but that's normal. However, I can certainly understand you concluding you don't have enough data to really be confident it's fully ready. The one thing we've determined in our testing is that if a particular service finds some unexpected problem at any level of the JUnit 5 upgrade (starting with simply upgrading the surefire version to 3.0.0-M7), they can simply stay with JUnit 4 and Surefire 2.x, and they can move forward with that, while we file that as a scenario that we need to troubleshoot. We can live with that. On Wed, Jun 8, 2022 at 6:20 PM Olivier Lamy <[email protected]> wrote: > On Wed, 8 Jun 2022 at 04:29, David Karr <[email protected]> > wrote: > > > Now that M7 is released, I have a feeling I know the answer to this, but > > what are your thoughts about when a full release will go out with these > > latest changes? I'm currently evaluating whether we can upgrade our > > internal platform to support Junit 5. As far as we know, M7 will address > > the last problem we were seeing (buffer overflow), and we'll be testing > > that this morning, but my "platform" team only has a small set of > services > > we can easily test platform upgrades with. Our platform is used by a > large > > number of services. Using a "beta" version carries some amount of > > indeterminate risk (sort of redundant), so I have to be more careful > about > > planning for contingencies if we discover unexpected problems from the M7 > > version in other services we don't directly support. Those contingencies > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > Well I think using Mx is because we are a bit conservative :) > version naming is a bit of a chicken and egg problem! > We'd like to have more feedback/tests (even issues :)) etc.. from the real > world but as it's called M* people do not upgrade. > I do not see real issues with junit5. > BUT I think there are still some problems with JPMS and the default (and > non configurable) options used. > Let me explain that. First you need to know surefire (and few other plugins > such compiler, javadoc) rely on a library called plexus-java which from a > list of jars will parse all the module-info files to build a sort of graph > and so build the module-path and the classpath. > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > February 2020. > 3.0.0-M6 has been released at the end of March 2022 with plexus-java 1.1.1 > from January 2022. > It's always 2 years between those releases and by the way plenty of changes > in the plexus-java library (because of some issues with compiler, javadoc > etc..) > (With my committer of Jetty project hat) we use JPMS now and moving from > 3.0.0-M5 to M6 is impossible because of > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > change in plexus-java > and now upgrading to M7 is impossible either because of another issue > (which I need to create a jira for it). (but there is a gist explaining the > problem here > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > ) > Ideally I'd like to have more configurable options for jpms (e.g module > graph resolution) because actually it's based on some assumptions which can > be wrong for some use cases. > I'm currently collecting use cases etc... Then I will create a Jira to ask > for comments (such as what do you want guys to be configurable for jpms: > test scope should be in module-path or classpath, same for provided, do we > need to add automatically providers to the module-path even if it's a test > dependency). > I think this needs to be fixed before removing the M* :) because jpms get > more and more adoptions now. > > > > > > > > > > > > > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy <[email protected]> wrote: > > > > > Hi > > > The vote has passed. > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > PMC quorum reached. I will continue the release process. > > > > > > cheers > > > Olivier > > > > > >
