On 2 January 2017 at 20:34, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote:
> > > 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!) > Link works unless you have HTTPS Everywhere browser plugin installed. See https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-13219 for my request to make available over https also > > 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 >> >> >
