cstamas commented on PR #765: URL: https://github.com/apache/maven/pull/765#issuecomment-1182947998
> What about using this slower but more accurate implementation in `versions-maven-plugin`? It is clearly the place it belongs to since this is not a check you want for each build but when you manage your versions _only_ IMHO. Regarding "slower" implementation, we already tasted it, as * users majority still use 2.x m-install-p/m-deploy-p (8 years) as we did not provide 3.x release of it * users majority still use 2.x of surefire (as it is in M phase for 4 years) * we keep finding codebase not touched for 5-10 years that needs cleanup When Maven3 was released, there was an agreement to lift plugin versions to "align" it with Maven, so 3.x plugins were being made. We failed to deliver that even with "moist important" plugins (those that make Maven be Maven), the m-install-p and m-deploy-p. As you know, to run Maven2 plugin, you need maven-compat. That said, Maven4 will NOT support Maven2 plugins (we will not span 2 major versions, no resources for that), but Maven4 will support 3.x plugins. Hence, Maven 3.9.x -- as being in "corner" for upcoming Maven4 -- should start "herding" our users to keep up, as in this experiment, to at least move to Maven3 level 3.x plugins. Any plugin relying on maven-compat (and sadly this is not explicit thing, only way to "assume" it is use of plugin-api 2.x) is becoming critical in user build IF they want to keep up. If not, let them stick with old Java, old Maven, old Plugins.... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
