On Thu, Jul 7, 2016 at 8:49 AM, Paul Benedict <pbened...@apache.org> wrote:
> 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. > +1, just like when you deprecate an API in Java. The trick for Maven is to define what deprecation means for itself. Of course that does not help you when you jump multiple versions at once, but at least you can then go back and update one version at a time. Gary > > Cheers, > Paul > > On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte <c...@schulte.it> wrote: > > > Am 07/06/16 um 23:32 schrieb Christian Schulte: > > > Am 07/06/16 um 23:19 schrieb Christian Schulte: > > >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch: > > >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote: > > >>>> Hi to all Maven users, > > >>>> > > >>>> If you like to help making the next Maven release better it would be > > >>>> nice if you could help a little bit. > > >>>> > > >>>> Please be aware of this *** This is not an official release *** > > >>>> > > >>>> I have created downloadable packages which are available from here: > > >>>> > > >>>> Windows: https://s.apache.org/qDs1 > > >>>> Linux/Mac: https://s.apache.org/Sn7X > > >>>> > > >>>> Every kind of feedback is helpful. > > >>>> > > >>>> Important hint: > > >>>> > > >>>> Based on the following issue > > >>>> https://issues.apache.org/jira/browse/MNG-5227 the optional flag > in a > > >>>> dependencyManagement was simply ignored with previous Maven > versions. > > >>>> This Maven version starts to handle that correct. If you have > problems > > >>>> with that please report. > > >>>> > > >>>> > > >>> > > >>> I believe this build (git hash > > 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the > fix > > for MNG-5227. The previous testing snapshot built from > > 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for > MNG-5227, > > but the fix was reverted to avoid breaking builds which relied on the old > > behaviour. > > >>> > > >>> (this is just based on my reading of the commit history) > > >> > > >> There is MNG-5935 which is fixed and has an impact on the optional > flag > > >> in dependency management. See this commit and its message. > > >> < > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e > > > > > >> and there is MNG-5227 which has an impact on the optional flag in > > >> dependency management. See this commit and its message. > > >> < > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a > > >. > > >> Someone on dev@ has reported that he is using the optional flag in > > >> dependency management (setting it to true) and that he has noticed > that > > >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he > > >> noticed it is not working before. What is important to know is that > > >> before the fix for MNG-5935 all managed dependencies were implicitly > > >> managing optional to false. Aether got updated to change the optional > > >> flag from 'boolean' to 'Boolean' and Maven has not been updated to > > >> reflect that. So instead of passing 'null' to Aether, it passed > 'false' > > >> meaning 'manage the optional flag to false' where it should have > passed > > >> 'null' meaning 'do not manage the optional flag in any way'. > > >> > > > > > > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to > > > test contained an Aether bugfix. That bugfix has lead to reports about > > > missing 'test' dependencies. See this commit and it's message > > > < > > > https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d > > > > > > and the description in the bugtracker > > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=486740>. > > > That bugfix has been reverted in 3.4 but will re-appear as soon as we > > > update Aether which contains that bugfix correctly. > > > > > > Regards, > > > > > > > > > Long drum-roll here. > > > > What we were discussing on users@ was how we are going to ship bugfixes > > like these to the users. Either they will notice something has not > > worked before and starts working or they will not notice anything and > > just complain the build is no longer working as before. And we cannot > > revert things like these for eternity. > > > > Regards, > > -- > > Christian > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
