Am 12/31/16 um 12:13 schrieb Guillaume Boué: > > Having a vote on all changes to master sounds too much. I think it > should be up to the developers to always raise discussions whenever a > change would have impacts on existing ITs, or whenever a new feature is > considered to be added. Bug fixing should be able to be pushed easily;
It's the bug fixing that has lead to resetting various master branches. Someone grabs a recent snapshot, notices it does not work for him, starts to bisect core although I stated multiple times that current core is uncovering bugs in the poms. Current master is passing all core ITs, all plugin ITs and also can be used to build all plugins, if you manually change to a different plugin tools release (-DmavenPluginToolsVersion=3.3 or 3.5). Download Maven 3.0-alpha-1 and try it with that. Current master is a snapshot - that's pre alpha - and is in a way better conditition than what got released as Maven 3 alpha, beta and the first 3.0.x releases. We would have to release a few plugins so that we can upgrade the default plugin version in the core to those releases and we would then be ready to release that as 3.4.0. Number of fixes to plugin POMs was lower than 10 commits. During all of this quite a few other bugs have been identified in the core, the ITs, the plugins, the plugin ITs, etc. All of this is fixed. We are now resetting all of this only because there is no trust. Committing to master means there must be consensus *before* things get committed. It does not make sense to put any effort into fixing bugs if all this gets you is requests to revert and endless discussions about everything. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
