David, Sending from my mobile, so will be short. I wrote the roadmap with purpose you was talking about. We can discuss it in a voice conf which would be much faster and you can help us too but it would not be done by the way to fire a random PRs. I neededed a break because of my job and illness but this happens. Regarding the release of 2.22.3, this is ready to go. Maybe somebody wants to backport some latest fixes...
T Dňa pi 10. 6. 2022, 19:52 David Karr <davidmichaelk...@gmail.com> napísal(a): > 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 <ol...@apache.org> wrote: > > > On Wed, 8 Jun 2022 at 04:29, David Karr <davidmichaelk...@gmail.com> > > 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 <ol...@apache.org> wrote: > > > > > > > Hi > > > > The vote has passed. > > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > > > PMC quorum reached. I will continue the release process. > > > > > > > > cheers > > > > Olivier > > > > > > > > > >
