On Monday, 2 January 2017, Michael Osipov <micha...@apache.org> wrote:
> Am 2017-01-02 um 21:34 schrieb Stephen Connolly: > >> 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? >> > > Agreed. Will do tomorrow. > > 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 >> > > I sew what you are after. It makes sense. Though, I dislike to change > coordinates in a patch release. This deserves a minor release (at least) > for the relocation. > So the relocation is what 3.5.0 is 3.5.1 will be then just a version bump If we rename packages that would be 4.0.0 at least (unless we retain a compatibility shim... in which case it could be 3.6.0) Next release, with real changes, can be 2.0. 3.0 will likely include new > package names. > > Michael > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
