Le mardi 20 décembre 2016, 03:45:47 CET Christian Schulte a écrit : > 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. we are in a stabilization phase, to make a long awaited release which has already numerous questions attached for end users migration: that's not the time to add more breaking changes
> > > "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. yes: that's why working on changing it requires unusual strategies > > >> 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. All ITs are passing: that's a first minimal step = "it can fly" the next step is to estimate how much efforts it will require for users to upgrade (for which benefit): do you have a list of plugins versions that are failing with the new plugins resolution algorithm? Putting it on a Wiki page would be useful for change management. and there is even eventually another step: can a pom be configured to work both with the old algorithm and the new one? > > > 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. one week on a feature branch is the way to go for such key changes. This is true in general, and even more when we're trying to do a release > > > 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. still has to be proven and documented: I want to help on the wiki page, please give some initial list and I'll work with you on it > It may break broken builds working before. Different story. that one is what makes me mad: you're playing like a purist kid, against normal users If it was working, it was not broken: it may have worked by "chance", yes, and we must work on removing this risky "chance" part. But you can't start by telling users their build was broken: no, it worked > > > 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. time for exceptional release branch, because this is exceptional change > 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. yes, collaboration is positive: but you're still avoiding the fact that you just postponed the 3.4.0 release for I don't know how much time. It seems you're missing empathy for the rest of the team and for users: that one is a lot less positive :( I hope this is the last time you're working on master for such risky key changes: please confirm Regards, Hervé > > > > > > --------------------------------------------------------------------- > 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
