maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Date Mon, 02 Jan 2017 21:08:43 GMT
Am 2017-01-02 um 21:34 schrieb Stephen Connolly:
> On 2 January 2017 at 20:15, Michael Osipov <michaelo@apache.org> wrote:
>
>> Am 2017-01-02 um 20:35 schrieb Stephen Connolly:
>>
>>> On 2 January 2017 at 18:49, Michael Osipov <michaelo@apache.org> wrote:
>>>
>>> Am 2017-01-01 um 15:51 schrieb Stephen Connolly:
>>>>
>>>> On 1 January 2017 at 00:55, Michael Osipov <michaelo@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. Next release, with real changes, can be 2.0. 3.0 
will likely include new package names.

Michael



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message