maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
Date Mon, 02 Jan 2017 21:25:25 GMT
On Monday, 2 January 2017, Michael Osipov <michaelo@apache.org> wrote:

> 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.


>
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message