If to "blow up" is unacceptable, then what is the documented way for a Maven client to deal with a <modelVersion> it doesn't fully support? Keyword here is *fully* support. Minus tags and values specific to the 4.1.0 POM schema, a high-percentage of the configuration should be parseable by an older client. Perhaps this is where the discussion needs to lead? How Maven should behave differently between a future minor version POM and a future major version POM? I am hinting at a strategy for forward compatibility.
Cheers, Paul On Tue, Aug 23, 2016 at 4:45 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/23/16 um 01:12 schrieb Stephen Connolly: > > On Monday 22 August 2016, Christian Schulte <c...@schulte.it> wrote: > >> That won't scale. What is to note here is that the XML schema or > >> anything syntax does not change between 4.0.0 and 4.1.0. It's just that > >> Maven 3.4 performs the dependency management import differently when > >> operating on a 4.1.0 POM instead of a 4.0.0 POM. > > > > > > But what happens when maven [2.0-3.3.4) download that Pom? > > > > If the answer is "blow up" then I am -1 > > Just to throw another one into the discussion. How to handle a change in > behaviour like this? > > <https://issues.apache.org/jira/browse/MNG-5761> > > Committed to the maven-3.x-next branch already. > > <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h= > d69dd31389b62264686e339e6c60dc5d7c26d4b1> > > See my last comment on that issue. This requires a bump in model version > as well. Version ranges make it impossible to deploy the effective > dependencies after management (classically or transitively) again. > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
