Am 11/15/16 um 23:41 schrieb Jason van Zyl: > > You obviously don’t work with anyone who has a system with any number of > users. No one has said the system cannot change, but you repeatedly keep > changing stuff that potentially has huge impacts on users and it doesn’t > bother you at all. I just really don’t think you’ve ever had to deal with > more than a few users. Almost none of the changes are well documented, > there’s no release notes, we’ve told you to roll back or stop making > behavioral changes. It currently may not be ideal, we all may consider it’s a > bug, or we may all agree it’s wrong. A minor version is not the time or place > to change it. >
Damn it. I haven't changed a thing and have been asking on how those changes can be integrated. I would like to avoid loosing track here. Give me a branch I can commit things like that to and I'll be done with it and can forget about it. That's all. That branch needs to be something permanent others can integrate into as well. And it needs to be clear what version is in those poms on that branch. 4.0.0-SNAPHOT, 5.0.0-SNAPSHOT, what? Based on what you just said, the 'maven-3.x-next' branch is not the right place for this so that I can delete it. If you look at <https://issues.apache.org/jira/browse/MNG-6056>, that's also nothing we could do for 3.5. And I'll need to revert bug 486740 in the maven resolver now as well, as that bug fix also cannot be shipped according to what you just said. I am running circles and would like to just finish up on various things so that I can forget about them. It's good that there is MRESOLVER in JIRA now. I could attach patches there, for example. > Such is life. Again if you want to make drastic changes take all your changes > and put them on a 4.0 branch and do whatever you want. It’s an open source > project so you’re free to do so. Changing behavior and changing tests that > validate that behavior is just really such a bad, bad idea. Please go make a > 4.0 branch and feel free to do whatever you want. That's all there is to it. Should I put 4.0.0-SNAPSHOT into those POMs? Could someone create a matching version in JIRA then, please? And a next version for MRESOLVER as well, please, where things like that can be tracked with. Can we please line up all of this with everyone and with whatever changes others have in mind. Regarding the tests. I absolutely disagree in the way those tests have been written. For example: When that specific IT has been written, there should have been a plan on how that will have to look in the future. I mean: super( "[2.0.6,)" ); in that constructor with no upper bound although the author himself knew that this behaviour will change in the future is what requires it to be changed. There should have been an upper bound right from the start: For example: super( "[2.0.6,3.0)"), and a corrosponding test with super( "[3.0,)" ); when known that the test is really testing the "final" behaviour. So this missing upper bound is what is requiring changing that IT. The author knew that test will not be valid for all upcoming Maven versions but had no idea on what upper bound to use. Reviewing all those ITs is a huge effort due to this. Fix something, review all failing ITs and decide on what test is incorrect is something very error prone. That's just trial and error and will not solve things like this once and for all. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
