maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs
Date Sun, 28 Aug 2016 17:26:24 GMT
+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 <tibordigana@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+s40175n5878775h65@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 <cs@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@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+s40175n142166h86@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message