Am 21.12.2016 um 08:04 schrieb Hervé BOUTEMY: > remember: we'll have to explain users why we did a breaking change > I don't think such an explanation will be possible for users: for long-dev > like me, it's hardly a valid explanation > > Can you explain in plain english some cases, please? > > And remember we'll require to prepare a list of known plugins > > When fixing the code means breaking user builds at large scale (which I fear > is > the case here), there is change management to prepare: the team can help, but > you need to help the team first
It's mainly a matter of updating the documentation and providing meaningful examples in the release notes and so on. For this we first need to decide some kind of roadmap to what will be the next Maven release. It has been requested to add some kind of command line option to be able to opt-out of the dependency management fixes (legacy-dependency-management, for example). That would be something I would still need to do. It mainly depends on what is decided to be released. There are no issues I am working on at the moment. Everything I started to work an last year in december is finished as of a few hours ago. The next commits from me would be for the Maven site and for the release notes. Except that command line option. Ok. It really depends on what will pass the next release vote. Personally, the current resolver master could be released as 1.2.0 together with the current Maven master as 3.4.0. There are these two bugfixes (MRESOLVER-8 -> fixes plugin resolution, MRESOLVER-9 -> fixes dependency management) in the resolver having that noticable impact on the resolution. That's a all-or-nothing decision. If current resolver master is release as 1.2.0 and the next Maven release will use that resolver version, all of current Maven master should go into the next Maven release as well. If the next resolver release does not contain those bugfixes, all of those resolution and dependency management impacting changes in Maven should not be released with that unfixed resolver. Do it all in one release or don't do it. Just needs to be decided. That's not my decision. Cherry picking my changes would be easy for me to do. The first line of the commit message is what makes this easy. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
