Am 12/19/16 um 08:32 schrieb Hervé BOUTEMY: > Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit : >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: >> Thats what the resolver does when requested to collect dependencies for >> a POM or for a dependency. I just made two selector implementations >> behave the same. > that's the risky job: changing key Maven core feature => require a lot of > explanation for everybody before changing it on master > And a choice on when to include such breaking change
I consider master "bleeding edge". This is where everyone is working on and what is used by the developers themselves. Main point of collaboration. Not questioning your points. We are talking about those things solely because I pushed them to master. That's the intention and that has lead to a state I would not mind to release. That's a different story, I know. > "I'm not the author": wrong conclusion > right conclusion is: "change with extreme care, because even if your > intentions are the best, such change will bite a lot of users" I try to be that careful. The resolver codebase is quite special. What appears to be common sense patterns applied turns out to be tweaked like mad under the hood applying some custom only the original author knows what's going on patterns everywhere sometimes in conflict with what is common sense. I may be totally wrong with this. That's my impression having read large parts of that codebase. Continously re-reading may yield different results. >> What is broken? > remember we have thousands or millions of users: the change will make a lot > of > builds fail All ITs are passing. I really do not expect that much of breakage. > As a conclusion: you're working on changing dependencies and plugin > management, which is the most difficult and risky part of Maven changes, that > has a lot of impact on every user (Maven developers being only the first > level > of users) > Then this require extreme caution that you missed at the moment All ITs are passing. It took a weekend of work to reach that. Ok. In between master was in an unusable state from time to time but never for more than 2 hours. It maybe is a matter of workflow. I fetch only before I want to push something but I am pushing often. So this may not work when not fetching for weeks. > I want to be supportive of such changes, but that will require other working > methods for the whole Maven team to be able to explain to ouor end users why > *we* changed something that breaks existing builds It is not breaking existing builds. Really. I haven't changed things that dramatically. Hopefully. It may break broken builds working before. Different story. > On the short term, I think that everything can't go into Maven 3.4.0 but will > have to be explained,documented and included in a future version: perhaps > Robert's idea on rewinding to a past state to rework what goes into Maven > 3.4.0 and what will go in a future version will be the best solution to help > us work back on a shared vision and clean codebase Maybe create a 3.4.0 branch forking from somewhere you feel comfortable with. The same for the resolver. Time for release branches then. Means instead of everyone creating theire own branches, let everyone collaborate on master and have a release branch kept in a state one can cut a release from whenever needed/wanted. Maybe some release manager decides what is merged from master and what not. It's possible to cut releases in between whenever needed/wanted/requested/required that way. Collaboration is important. It has helped a lot getting those changes sorted out. In fact, we are still sorting things out now. That's something very positive. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
