ok there is only one additional point: when things were working previously because of special cases that were handled with specific code previously, the change has to be done with extra care: that's where the general intent of fixing things has the immediate opposite effect
Then always we careful on the idea of "fixing" when it comes to Maven core, since the effect is not always limited to the initial intend: there are so many plugins, so many situations Regards, Hervé Le lundi 20 mars 2017, 00:20:33 CET Christian Schulte a écrit : > Am 03/19/17 um 23:32 schrieb Hervé BOUTEMY: > > for you, documentation is always right? > > That's the first time I see that documentation is more important and > > always > > more accurate than how the tool works > > > > If there is a discrepency between how the tool works and what is written > > in > > documentation, there is work to be done to define what part has to be > > improved to match the other: I don't make any judgement on "fixing", just > > that the bug is in the discrepency > > That's what I meant with "when there is consensus the > documentation/specification is stating the intended/correct behaviour" > First thing to validate is the documentation/specification. If that is > accurate, work on fixing code can be started. If that is not accurate, > work on fixing the documentation can be started. Both bugs. Either in > code or in documentation. That's mainly what I did on the pre-reset > branches. Make the code match the documentation (site and javadoc) when > I was sure the documentation is describing the expected behaviour and > the reports in JIRA were backed by valid analysis or example projects > demonstrating things are misbehaving. > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
