Based on the responses it looks like most agree on moving forward to Maven 4. Regarding the concerns of Karl Heinz I agree with Michaels proposal: If there is a real need for Maven 3.7.0, let's cherry-pick those commits we want to include.
I'll update the version tomorrow and rename the versions in Jira. This means we can also have a look at issues that were postponed to Maven 4, because they might break some builds. Would be great if we could clean up those list of branches. thanks, Robert On 21-11-2020 02:30:45, Hervé BOUTEMY <[email protected]> wrote: Le lundi 16 novembre 2020, 17:15:39 CET Michael Osipov a écrit : > Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise: > > Hi, > > > > On 12.11.20 20:00, Robert Scholte wrote: > >> Hi, > >> > >> It is already several years ago where we started discussing about > >> Maven Next Generations. > >> Clearly we needed to work on the pom, because over time we're facing > >> more and more limitations. > >> For (Maven) Central the Model 4.0.0 will be required pom format, > >> there's no discussion about that. So we needed a new architecture > >> where there's a local pom that is transformed to Model 4.0.0 or where > >> it can be generated. > >> With the implementation of MNG-6656 and the improvement with MNG-6957 > >> we've made the first and important steps based on pom transformation. > >> If this concept proofs itself, we can start thinking about enhancing > >> the pom model. > >> > >> When talking about Model 5.0.0 it looked like it would be great to > >> introduce it for Maven 5. There was even a period where we thought > >> about skipping Maven 4, just to sync the Model version with the Maven > >> version. > >> However, we discovered that this would be a huge change, and that we > >> would probably need a couple of Maven 4 releases before moving to > >> Maven 5. Maven 4 would consist of preparation releases. > >> I've started writing the build/consumer to proof that the it is indeed > >> possible to separate the local pom from the distributed pom, even > >> though they both are currently still Model 4.0.0 compatible. > >> The original idea was: > >> Maven 3: build/consumer feature disabled by default > >> Maven 4: build/consumer feature enabled by default > >> > >> Maven 5: Model 5 > >> > >> We were worried that this wouldn't give us enough feedback. > >> maven-integration-testing shows that build/consumer does work. There > >> should be enough trust to enable it by default, it shouldn't impact > >> existing projects (the last find by Michael was actually great. It > >> demonstrated the effect when using threads. The fix made sense and > >> Maven was stable again). But it is simply not enough. We need much > >> more feedback. > >> > >> Meanwhile other improvements have been done, that has impact: > >> - new behavior of reactor commandline arguments > >> - upgrade of default versions of plugins per packaging type > >> - requiring Java 8 > >> - Maven wrapper > >> - there's a PR waiting that will shift the logic of the > >> ProjectBuilder/ModelBuilder. As this is quite important for more > >> people to understand, I'll record a Q&A with Maarten+Martin soon and > >> share it with you. > > > > it would be nice to have a kind of information here on the dev list to > > see what kind of consequences this has? > > > >> There are probably more, but all these already defend my opinion about > >> the next Maven version. > >> > >> To me it is not a Maven 3 anymore, we're reached a point where we > >> should start calling it Maven 4. > >> The next release should probably have an alpha suffix, just to give > >> users the chance to do alpha testing. > > > > With a new major version we start to produce high expectations with 4.X > > > > I would suggest to do 3.7.0 first with support: > > > > - new behavior of reactor commandline arguments(?) ? > > - Maven 3: build/consumer feature disabled by default (??) > > > > Needs more testing of corse... > > cause this would help a lot of people... make it easier > > and get rid of flatten part.. > > - Signing of artifacts etc. needed to solved first. > > > > - requiring Java 8 (not a big issue; done for several Maven minor > > versions before) > > - Maven wrapper > > > > getting all that above working fine... and mark a number of classes / > > parts/modules as deprecated ... which has not being done yet. > > > > Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the > > adoption is more hesitant than for a 4.0.0 which is a major version > > upgrade.... > > > > > > Maven 4.0.0 > > > > - build/consumer feature enabled by default > > - Remove old stuff > > - break things and improve the build pom ... > > - Remove maven-compat .. ? introducing maven-compat3 ?.. > > - Maybe JDK 11 base? (LTS?) just a thought > > - > > > > Also making a 3.7.0 before so we can learn things related to > > build-consumer pom before going to Maven 4.0.0 ....where we can break > > things which we can not in 3.7.0 ... > > Hi Karl, > > I don't think that that we should press such an amount of changes into a > minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and > cherry-pick selected changes.... going to 4.0.0-alpha is a way to avoid additional complexity of feature flags and an explicit testing period: even if we feature-flag build/consumer feature, there are many changes that require more serious testing IMHO than going directly to 3.7.0 with implicit high confidence > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
