FWIW, I ran maven integration tests (commit 73a2b7) against current maven master and got this
> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0 Running the same test checkout with Maven 3.3.9 > Tests run: 771, Failures: 0, Errors: 0, Skipped: 0 -- Regards, Igor On Wed, Nov 16, 2016, at 11:02 PM, Jason van Zyl wrote: > So have you not asked, after committing changes, if something should not > be rolled back? If you can take the integration tests from the commit > right after the 3.3.9 release and Maven master works against that I’ll be > perfectly satisfied that we will not be breaking the user base. > > > On Nov 15, 2016, at 3:42 PM, Christian Schulte <c...@schulte.it> wrote: > > > > 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 > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Takari and Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > > > --------------------------------------------------------------------- > 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
