+1 Le dimanche 28 août 2016 12:57:52 Robert Scholte a écrit : > Hi Tibor, > > There's no need to hurry to for Maven-4.0.0 just because of the > modelVersion. Maven2 was already using it, we may assume that users > already know about this. > I'd really prefer to stay on 3.x and go to 5.x once we've extended the > model to version 5.0.0. (I don't mind skipping 4.x if that's the case) > Users may expect huge changes when going to the next major. > In case of the 3.0 it was most of all architectural, I wonder if most > users noticed the changes. However, it still took a long long time to > convince users to switch from 2.2.1 to 3.x > > thanks, > Robert > > On Sat, 27 Aug 2016 22:42:49 +0200, Tibor Digana <tibordig...@apache.org> > > wrote: > > 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-SNAP > >> SHOTs-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=unsubscri > >> be_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4O > >> TQ5MjEwMg== > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
