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