Robert>last time their argument was that they didn't have enough committers to also maintain a maven plugin
TL;DR: I'm neither Maven nor Checkstyle committer, and I'm inclined that the PR should be declined. The case is as follows: there's a method in Checkstyle which is a no-op for 3 years or so. For some reasons (aesthetics?), Checkstyle developers decided to drop the method. They know the method is used by third parties. ^^^ What is the reason to drop a method you know is used by third parties? The consequences would be: 1) Maven committers and PMC would have to release a new plugin version (stage, verify, vote, publish dist) 2) Lots of users will face an error while trying to use never Checkstyle version. For example, In 99% of the cases, I just upgrade Checkstyle version, and I have no clue what is my version of maven-checkstyle-plugin. 3) Of course, their builds will fail. Of course, they will be able to Google the error and they will learn they need to bump maven-checkstyle-plugin. I'm not sure Checkstyle developers understand ASF release process, and I'm not sure they fully understand that "making a release" is not like a "pushing Git tag" :( I'm not sure Checkstyle developers understand they are creating a painful experience for the end-users :( This causes pain for Maven committers, PMCs, and for end-users who will blame all the issues on maven-plugin (because it was "too old, not releasing soon enough, etc, etc"). It does impact Maven in a negative way (not just the plugin), because, you know, at the end of the day it will be like "-- Maven never works -- Realy? What's that? -- Don't remember, there was a problem with one of the Maven core plugins..." What I mean here is like no-one would file a single issue to Checkstyle team for "breaking backward compatibility". I guess it would be better if they will be responsible for the decisions they make. It looks like there are two ways to proceed here: A) Decline the PR, and keep the method at Checkstyle side. Then no changes to the plugin are needed, and everything is good. B) Ensure the plugin version is exactly the same as the main Checsktyle version. Then end-users could specify a single property like "checkstyle.version", and use it for both plugin and checkstyle (well, they won't need to specify checkstyle then), and it would ensure the plugin is always compatible with Checkstyle engine. C) Accept the PR, and make sure Checkstyle will keep the method available for 5 more years (or so) to ensure everybody has migrated to the new plugin version. I guess "B" implies the plugin must be moved under Checkstyle repository so they could perform simultaneous releases (engine + Maven plugin) I do not think "C" is good because, well, I doubt Checkstyle developers are ready to wait 5 more years, and it looks like they are going to drop the method as soon as the new plugin version is released. Robert>To me moving the plugin would help both projects In practice, Checkstyle developers might be not that familiar with "Maven conventions": ways to resolve ClassPath, ways to configure properties, etc. So it makes a certain sense to review the plugin implementation by someone who understands how Maven should feel. However, "ASF release" overheads seem to be very visible (to PMC), especially when the only things to review are like "oh, an empty method is dropped" :( Vladimir
