Hey all, my thoughts on these questions are quite that we should keep it as simple as it is:
I see value in keeping the versioning and its semantics with the Maven API at the first slot. This makes it an easy to see indicator and keeps the experience /knowledge of long time Maven users. About the question for breaking changes: The minor version (2nd slot) can be the indicator for major changes (breaking or not) - don‘t forget the documentation aside the version number. We can easily describe the version semantic in general and list/highlight (breaking) changes in the release notes or maybe add an addional indicator (eg a „breaking“ flag in the versions overview). Also remember yourself: With Maven 3.9.0 the required Java version to run Maven was lifted to 8 - so breaking change without increasing the first number - indicated by another color (and the different number) in the java coloumn on the release page. At my work we do similar versioning semantic like the Maven one: our XSD where the first number is equal to version of the system of our major internal service provider (who handles in- and outcoming files). Greetings Matthias Von meinem iPhone gesendet > Am 06.03.2024 um 14:59 schrieb Tamás Cservenák <ta...@cservenak.net>: > > Howdy, > > We have several topics that need to be discussed. > > I. Core Plugin Versioning > > History: When Maven2 was born, and started using plugins "as we know them > today" (Maven 1 was a very different beast), the Core Plugin versions were > started as 2.0 on purpose. Just check the Maven Central for historical > versions, some examples: > * clean > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/ > * compiler > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/ > * jar > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/ > * surefire > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/ > * dependency > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/ > > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the > beginning. Later on, when Maven3 came to existence, it was able to use > Maven2 plugins, the plugins were slowly migrated to become "Maven 3 > plugins" (Maven2 could not use them anymore). This was denoted by the "3.x" > major plugin version jump. > > So far, we have no 4.x plugin release of anything (M releases do not > count). But my question is the following: > > How should we distinguish similar changes for Maven4? > > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3 > will NOT be able to use anymore (will be incompatible). Similarly as > before, Maven4 CAN run the "Maven 3" plugins, and will retain this > capability for some time. But other ways it does not work, nor never worked > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran > Maven3 plugin). > > For me, the logical answer to this question is the use of major version > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3 > plugin" (Maven2 incompatible). > > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will > confuse the hell out of our users. At least that is what I think. > > II. Consequence: How to interpret Core plugin versions > > As can be seen above, so far the major version of the plugin was kinda > showing "which Maven API level" is the plugin. > > So, it begs the question: HOW to interpret the Maven Core Plugin version? > > My interpretation was always: "shift it once left", meaning: Core plugin > version "3.2.1" MEANS: > - Maven API version: 3 > - Core Plugin version 2.1(.0) > > III. Consequence: How to express Core plugin "breaking change"? > > Today, everyone expects a "major version jump" to express breaking changes. > BUT, as explained above, that would be totally misleading here, and would > break the "customary law" that Major expresses Maven lineage. > > Ideas and opinions welcome. > > T --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
