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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
