I supposed to align Maven 4.x with model version 4.0, and then Maven 5.x with model version 5.0.
I supposed to directly release Maven 4.0.0 instead of 3.4.0. Why we have to control model version and support it if the XSD schemaLocation is already defined: http://maven.apache.org/xsd/maven-4.0.0.xsd ? Is this double definition (xsd schema and modelVersion)? On 8/27/16, Paul Benedict [via Maven] <ml-node+s40175n5878775...@n5.nabble.com> wrote: > > > Christian, I argue this is a matter of perspective in regards to "solve". > > There are two things to solve: > 1) Introducing new functionality with POM 4.1/5.0 > 2) Introducing acceptable responsiveness to the new POM by older tools > > Point #1 can be introduced in whatever version of Maven, that is true, but > it does have impact on Point #2. I've come to this conclusion based on some > of the push back seen in this thread. If I may emphasize what concerns me > most, it is the question of how older versions of Maven will be able to > cope with something it cannot understand? I believe the best way to > separate out these two concerns is to have separate lines of development -- > Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict > and collide. The two concerns are admittedly related, but they don't need > to be developed together because they are distinct enough in their > behavior. I'd think you really want Maven 4.0 development to be as free as > possible in terms of building out new features, and then letting the 3.x > branch react to them in the wild. That's my formula for success which I > propose to the development team here. I don't think it makes any sense to > introduce such a grand feature in the 3.x line because it obscures the need > to devise acceptable responses for older tools. > > Pretending that Maven 3.4 (for sake of argument) started to gracefully > handle future POM versions, the problem yet remains for Maven versions > prior to 3.4. That's true. However, if agreement can be found in 3.4 for > how to gracefully handle, and if that design plan is documented well, such > concerns could be back-ported to even older versions, no? Clearly this > doesn't help people who refuse to upgrade, but my emphasis here is about > mitigation for those users who can tolerate a patch release. I'd rather > have a plan in place to help those who want to help themselves, than do > nothing at all. > > With that said, it is really up to how 3.4 (for sake of argument) should > gracefully handle the new POM versions. Many forks in the road here leading > to different design answers :-) However, I find that to be a secondary > concern, at this time. The first step is really deciding what I proposed: > introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can > clearly answer that big picture strategy (and you know my opinion on that > matter), you can then begin to debate how best to be backward compatible. > > Cheers, > Paul > > On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <c...@schulte.it> wrote: > >> Am 23.08.2016 um 15:53 schrieb Paul Benedict: >> > I advise to not introduce any new POM version in the 3.x series. Please >> do >> > that in Maven 4.0 where you can blue sky ideas and green field the >> > development. >> >> And how would we solve the issue at hand in Maven 4? We increase the >> model version in Maven 4 to 5.0.0 and then? We do not run into exactly >> the same issue we are currently trying to solve? Postponing to Maven 4 >> is not solving anything, really. >> >> Regards, >> -- >> Christian >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878775.html > To start a new topic under Maven Developers, email > ml-node+s40175n142166...@n5.nabble.com > To unsubscribe from Maven Developers, visit > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== -- Cheers Tibor -- View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5878816.html Sent from the Maven Developers mailing list archive at Nabble.com.