Christian, you are right that introducing a warning does delay delivering the fix. Thanks for pointing that out. With that said, it's not all that bad because there are some choices...
1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix enabled, and ask users@ to concurrently test both. 2) A variation of #1, publish SNAPSHOT from the feature branch that contains the fix enabled. 3) Do something Oracle-ish like introduce a command line option to enable prototype features. Pretending that -Z represents that new option, using -Z:MNG5277 would tentatively enable the fix.... and perhaps any -Z option would spit out a warning into the log saying you turned on an incomplete feature at your own risk. To your point about "cluttering the different code bases", I personally just consider it a necessary development tax. Where's it possible, spit out the warning; otherwise not. Please also note option #3 also "clutters" even more by introducing if-checking for different behavior. Since I'd rather have less cluster than more, I personally prefer emitting the warning with a // TODO or // XXX marker in the code so the fix isn't not forgotten (with a reference to the MNG ticket). Cheers, Paul On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte <[email protected]> wrote: > 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] > >
