Le jeu. 12 nov. 2020 à 22:14, Robert Scholte <[email protected]> a écrit :
> The discussion is first of all saying the next release should be > 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven 3 > releases unless we need to backport security fixes. > What to add to that release is the next discussion. > Signing is only relevant for releases, but I think most companies don't > sign jars for their internal projects. > For those developers the missing features don't matter, but they can > benefit from a huge amount of improvements. > I disagree, a release is not only about signing but also letting others consume artifacts you produce. Having a proof it works for us is important before considering it can be a released feature (on by default). Also agree we shouldnt put a lot of features per release so maybe just the pom one in alpha-1? This ensures people can test what we propose and not only something else more shining. > Robert > On 12-11-2020 21:55:51, Romain Manni-Bucau <[email protected]> wrote: > Hmm, if it does not work e2e then even an alpha is pointless cause nobody > can test it further than a hello world, was my point. > > Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a > écrit : > > > I don't expect that signing will work with the the first alpha, but that > > shouldn't stop us of collecting feedback. > > Also we need to have a look at all plugins that do something with the > pom, > > like every packaging plugin, maven-source-plugin, maven-release-plugin to > > ensure the "right" pom is added. > > > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even > > though they are stable). > > There's still enough work to reach 4.0.0, but most likely the first > alphas > > are already good enough for the majority. > > > > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote: > > Did we already do mvn or mvn plugins (multimodules) release with the > > consumer/producer pom feature? > > If so +1 to do a v4 with this new feature "for us" and v5 with real user > > features and align it with the xsd. > > > > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a > > écrit : > > > > > 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. > > > 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. > > > > > > WDYT? > > > Robert > > > > > > > > >
