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==
