Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: <c47131d4-6ae5-d030-e2a9-3f7d4273f1af@apache.org>
References: <CA+nPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw@mail.gmail.com>
 <26579279-f6d0-4bda-0e6f-b49b9c3ad851@apache.org> <CA+nPnMynkvEODRHwHniWdz3S_CiJA1EjFMqvJe5273dzfCfmsg@mail.gmail.com>
 <8a87997e-407d-93e5-aa0b-54e58c7fc288@apache.org> <CA+nPnMz37Gxt8cuufgb_mNunz+3CVB6gcdWxupSOn0euLvY2Bg@mail.gmail.com>
 <1fcb2e76-52a4-58fe-fd74-96fe2fa6ea4d@apache.org> <CA+nPnMwa7wZw7HyNGvPpu2=A==6PtV6G3BXBHePWTi57xSOs9Q@mail.gmail.com>
 <c47131d4-6ae5-d030-e2a9-3f7d4273f1af@apache.org>
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
Date: Mon, 2 Jan 2017 21:25:25 +0000
Message-ID: <CA+nPnMxftOLbU8K_OYP9HWOqop2fo2MNGXwhxCDE1T8TXbsp2w@mail.gmail.com>
Subject: Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a113d37d8a9d862054523309c
archived-at: Mon, 02 Jan 2017 21:25:34 -0000

--001a113d37d8a9d862054523309c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 fr=
om
>>>> 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 / regression=
s)
>>>> 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 bee=
n
>>>>> 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 fi=
ne
>>>> 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-o=
p.
>>
>> 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 coul=
d
>>>>> 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 versio=
n
>>>> policy was "effects on plugin API / dependency resolution"
>>>>
>>>> The squashed diff should be quite small, so I am fine with us adding i=
t
>>>> for
>>>> 3.5.0... I just am not stepping up to sponsor it
>>>>
>>>>
>>> I'd like to handle over this to Herv=C3=A9 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 an=
d
>> artifactId changes.
>>
>> (this was discussed on IRC with Herv=C3=A9 and Robert somewhere near
>> http://wilderness.apache.org/channels/?f=3Dmaven-dev/2017-01-02#14833891=
45
>> (if we could get the link to work!)
>>
>> Herv=C3=A9 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
>
>

--=20
Sent from my phone

--001a113d37d8a9d862054523309c--