On 2 January 2017 at 20:15, Michael Osipov <micha...@apache.org> wrote:
> Am 2017-01-02 um 20:35 schrieb Stephen Connolly: > >> On 2 January 2017 at 18:49, Michael Osipov <micha...@apache.org> wrote: >> >> Am 2017-01-01 um 15:51 schrieb Stephen Connolly: >>> >>> On 1 January 2017 at 00:55, Michael Osipov <micha...@apache.org> wrote: >>>> >>>> I just went through the list my issues. Here is a safe list I would >>>> >>>>> merge/cherry-pick into new master: >>>>> >>>>> FIX-3.5.0: >>>>> MNG-5567, >>>>> >>>>> >>>> >>>> Affects behaviour, I recommend 3.5.1 but I will not object if others >>>> feel >>>> 3.5.0 >>>> >>>> >>> This indeed changes behavior but behavioral changes should not be in a >>> patch version like 3.5.1, but in a minor. Moreover, Java supports ZIP >>> files >>> first-class citizens, we simply failed/forgot this here. >>> >>> >> Well that is why I see this as a patch fix. Changing behaviour where the >> original behaviour was a bug or a regression does not mean we have to bump >> a minor version. >> >> I think this and the plugin classpath building *bugs/regressions* are both >> perfectly valid to fix in a patch. >> >> >>> I still think that 3.5.0 is appropriate. >>> >> >> >> I still think that it raises the risk of marking the "no-op" change from >> aether to resolver as breaking existing builds. >> >> My plan is 3.5.0 in the next two weeks and 3.5.1, etc at a 6 week cadence >> thereafter. If you want I am happy to do 3.5.0 and 3.5.1 in more rapid >> sequence, but I really would like to keep dependency and classpath changes >> out of 3.5.0 and push them for 3.5.1 (where they are bugs / regressions) >> or >> 3.6.0 (which should be as soon as we think we are ready, not a year or >> two's time >> > > Agreed. > > >>> >>> MNG-5954, >>> >>>> >>>>> >>>> >>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low >>>> risk to drop-in replacement with 3.3.9 >>>> >>>> >>> Do not share, it is never read. I even asked on dev list and Jason >>> replied, it is safe to be nuked. >>> >> >> >> If somebody else seconds, then it is agreed (unless we have an >> objector)... >> just I'm not going to second it for 3.5.0 >> > > Anyone else? > > >>> >>> MNG-6029, >>>> >>>>> >>>>> >>>> >>>> I'd second this for 3.5.1 >>>> I have concerns with introducing for 3.5.0 as it affects how the >>>> classpath >>>> gets built and could cause behaviour differences between 3.3.9 and 3.5.0 >>>> (as it causes the test classpath to actually get resolved) >>>> >>>> -1 for 3.5.0 but I am open to change my position >>>> >>>> >>> It is actually two-fold, duplicate code and wrong scope. Fix has been >>> there for seven months without causing any IT failures. I think is is a >>> safe bet for an RC. >>> >> >> >> But it breaks my goal for 3.5.0... the duplicate code part is OK for >> 3.5.0... but the fixing the scope bug is why I remain -1. Perfectly fine >> for 3.5.1 >> > > Let's split it! What do you think? I am fine on the duplicate code removal for 3.5.0 as it should be a no-op. Create a new JIRA for the test scope change then and we can include that in for 3.5.1? > > > MNG-6102, >>> >>>> >>>>> >>>> >>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low >>>> risk to drop-in replacement with 3.3.9 >>>> >>>> >>> This is change in behavior and not subject to a bugfix. The default >>> behaves like before. >>> >> >> >> This does not affect dependency / classpath resolution, but we are growing >> changes for 3.5.0 and I would like to try and keep the non >> s/aether/resolver/g changes to a minimum. If you can find another seconder >> it's in. >> > > Anyone else? > > MNG-6106, >>> >>>> >>>> >>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low >>>> risk to drop-in replacement with 3.3.9 >>>> >>>> >>> This is actually a bug because maven.home can never be user.home/.m2 >>> >> >> >> >> This does not affect dependency / classpath resolution, but we are growing >> changes for 3.5.0 and I would like to try and keep the non >> s/aether/resolver/g changes to a minimum. If you can find another seconder >> it's in. >> > > Anyone else? > > MNG-6115, >>> >>>> >>>>> >>>> >>>> We need to decide on colourised logs for 3.5.0 or 3.5.1 >>>> >>>> >>> Colorize is a new feature, not a bug fix. Either 3.5 or 3.6. It could >>> also >>> be squashed into MNG-3507. >>> >> >> >> It's a new feature for logging, but it doesn't add new APIs to the *core* >> of maven. So I think we could put it in 3.5.1 if we decided our version >> policy was "effects on plugin API / dependency resolution" >> >> The squashed diff should be quite small, so I am fine with us adding it >> for >> 3.5.0... I just am not stepping up to sponsor it >> > > I'd like to handle over this to Hervé and make it his decision. I will > ping him in the ticket. > > MNG-6136, >>> >>>> >>>>> >>>> >>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low >>>> risk to drop-in replacement with 3.3.9 >>>> >>>> MNG-6137, >>>> >>>>> >>>>> >>>> >>>> I'd second this for 3.5.1 but I'm not objecting if others feel it is low >>>> risk to drop-in replacement with 3.3.9 >>>> >>>> >>> Rather 3.5 or 3.6, consider that the last Wagon release is quite old and >>> currently, there duplicate dependencies on Maven's classpath as layed out >>> in MNG-6137. >>> >> >> >> I don't see this being something that needs to wait for 3.6.0... 3.5.1 >> seems perfectly ok to me >> > > Why not 3.5 then? We update Resolver, why not Wagon? At last, Resolver > requires Wagon too as its transport... Because it will be a resolver that is cut from https://github.com/apache/maven-resolver/commits/1.0.x so that the only change between resolver in 3.3.9 and resolver in 3.5.0 is the groupId and artifactId changes. (this was discussed on IRC with Hervé and Robert somewhere near http://wilderness.apache.org/channels/?f=maven-dev/2017-01-02#1483389145 (if we could get the link to work!) Hervé will be adding the coordinate changes to that branch and then will cut a 1.0.3 release which we will then change MNG-6110's title to reference So you see the change in 3.5.0 should be a no-op from 3.3.9 > > > Michael > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
