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?
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...
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
