I'm a little concerned that this is somewhat incompatible with existing usage.

This code should be fully backwards-compatible as no existing methods are removed/modified and only new ones are added. Some consumers can be seen at https://mvnrepository.com/artifact/org.apache.maven.shared/maven-verifier/usages. In any case a migration away from the deprecated methods should be pretty straightforward.

It's more of a long term concern. Is anyone who's not the Maven project using this? If so, it's going to be really hard to remove the deprecated methods.

I agree that if we had a green field this approach is preferable.

It is standard way, first deprecated method with documentation how should be replace - and we do this step.

Next we release major version with removed methods in some time.

It's the standard way, assuming step 2 can in fact be done. Far too often, step 2 never happens and the deprecated code is never removed and supported forever.

Thanks for the link to mvnrepository. That's more usages than I would have guessed. My gut is that we're not going to remove these methods. Too many projects depend on them already. I think we're better off living with what we have.

We shouldn't stop development based on simple usage.

Eg. now many project migrate to JUnit 5 or use other test frameworks than JUnit 4.
We shouldn't implicate which framework should be used by final project.

In my feel many projects do not upgrade their dependency, so it is their decision.

Better stats is usage per version, like:
https://mvnrepository.com/artifact/org.apache.maven.shared/maven-verifier

@kwin - what with open conversations with @elharo

what with open conversations with @elharo

I think everything should be resolved now.

Resolve #150