Am 07/07/16 um 17:49 schrieb Paul Benedict: > If there is a change that will prevent a build from working, asking for > users@ testing is not the way to do this. The way to do this is to > introduce emit a "warning" first in the next version of Maven, and then > convert it to an "error" in the next version after that. We can't just say > to users "hey, we may break your build now so please test" -- that's not > nice of us. Let them test the warning, if anything, to make sure all cases > are correctly captured. If all cases are correctly captured, then > converting the "warning" to an "error" will be simple. > > I really propose we give users enough up-front notice that things are going > to break in a future build -- but not without introducing warnings into > their build first. Let's give time for the community to correct their POMs > without creating emergency changes for developers. >
Then that's the way we are going to deliver bugfixes. So be it. Any news on that 'feature toggle API'? Just emitting warnings everywhere is not always possible. There is no logger available everywhere. I really would like to capture things like these with an API. Having an API forcing you to add references to issues in JIRA and so on you can search usages and things like this. Cluttering the different codebases with warnings everywhere whenever a bug is found/a new feature is introduced means we will not fix the bug/introduce the feature but add a warning. So noone will have a chance to test builds with the bugs fixed/features enabled. Maybe we add a '-pedantic' command line option users can use to test "what will happen when Maven does error out instead of warning me". Someone still working on that MNG-6056 branch? We really need a shared component for this. It's not only about Maven core. Do we all agree on those feature toggles, BTW? Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
