Actually, for me the ideal would be a command line switch that could re-enable the feature that was deprecated. Then you don’t really have to wait a release, so long as it is documented. This makes sure user’s are aware since they have to take a minor action to continue to make things work.
Ralph > On Jul 7, 2016, at 9:27 AM, Paul Benedict <pbened...@apache.org> wrote: > > 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 <c...@schulte.it> 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: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
