Hi Romain, Thank you. I agree that there needs to be a middle ground.
I have also experienced painful upgrades in real systems. Applications and dependencies often evolve incrementally rather than being designed for every future requirement from the beginning. Over time, they accumulate assumptions, integrations, and behaviors that may only become visible when an upgrade changes them. Thinking more about Maven, I now better understand why this is especially difficult here. Maven's plugin ecosystem has existed for more than twenty years, and compatibility is not only about documented APIs. Plugins may also come to rely on lifecycle ordering, classloading behavior, model-building details, dependency resolution behavior, and other assumptions that gradually become part of the practical contract. Your point about stronger formal API boundaries in Maven 4 makes a lot of sense in this context. At the same time, it is probably impossible to predict every extension requirement for the next twenty years. What seems particularly important is having clear and sustainable boundaries: what is stable, what is experimental or incubating, what is internal, and how new extension points can be added when future needs appear. I am also starting to see Maven as more than just a build tool — it is also a kind of protocol layer in the Java ecosystem. It connects project models, plugins, repositories, dependency resolution, IDEs, CI systems, and many other tools. Upgrading such a protocol is naturally much harder than upgrading an ordinary application. >From that perspective, I understand much better why Maven 3 to Maven 4 requires so much care. If the Maven 3 to Maven 4 transition is necessarily painful, one valuable outcome could be a healthier boundary and extension model, making future major-version transitions more localized, predictable, and easier to migrate. Thanks again for sharing your perspective. This discussion has helped me understand the problem much better. Best regards, Josh
