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