On Thu, 9 Jun 2022 at 16:25, Romain Manni-Bucau <[email protected]> wrote:
> Well, I already wrote it on multiple threads but let try to refine that: > > 1. (Side note) we can need another thread ;) > 2. Surefire 3 is stable and reasons to hold a final release are internal > and not user facing so we can do a final > 3. JPMS is *not* supported for the reason you mentionned > well I wouldn’t say *not* but partially or incorrectly (but this is very subjective :)) anyway I created this for discussion https://issues.apache.org/jira/browse/SUREFIRE-2097 > 4. We never managed to get a version policy support so current state is > last version + best effort which means for surefire that there is no final > version supported (how can it be?) but also means we can do a new final > major version each week without much drawback so we can do a 3.0.0 now, a > 4.0.0 in a month supporting JPMS and even maybe a 5.0.0 in 2 months > dropping our legacy abstraction to align on mainstream ones instead of > stacking them (it is some work but hopes it illustrates we can do final > releases) > > Le jeu. 9 juin 2022 à 03:20, Olivier Lamy <[email protected]> a écrit : > > > 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 > > > > > > > > > >
