Excuse me if this has been previously discussed, but has using semantic versioning [0] ever been considered for versioning Maven itself? Maybe this could be adopted from Maven 4 onwards?
I’m a framework maintainer, and software that uses semantic versioning make users’ lives (including mine) so much easier, because a new release’s version number immediately makes it clear if backwards compatibility should be expected or not, if it brings new features (backwards compatible) or only fixes. Software that introduces breaking changes in a minor or even patch version makes everyone’s lives unnecessarily difficult in my opinion. Cheers, Nils. [0] https://semver.org/ > Op 20 mrt. 2023 om 20:02 heeft Tamás Cservenák <ta...@cservenak.net> het > volgende geschreven: > > Hey Ryan, > > (you might remember me, was committer on Enunciate project, while it was on > Codehaus) > > Let me start from the far end: When you say "Maven 3.x", you most probably > mean (or you want to mean) Maven 3.2.5 and "onwards" (3.9.1 inclusive). > Simply put, you should not strive to cover "all" from 3.0.x to 3.9.x, for > simple (technical) reasons: Maven 3.0.x used org.sonatype package for > resolver, Maven 3.1.x did not support Eclipse Sisu index usage, so the > "most sane" Maven range to cover today is Maven 3.2.5-3.9.1. Actually, this > is what we do at ASF Maven project as well, almost all "core" plugins are > declared as compatible with this Maven range (with some rare exceptions). > By targeting this range, you get rid of ugly problems like package renames, > and various issues and shortcomings (like forced use of Plexus XML, etc). > We also target Java 8 bytecode these days, we stopped supporting Java 7 and > older platforms. > > We, as contributors of the Maven project, simply have no resources to cover > 10+ years (3.0 is 2010, 3.1 is 2013) of legacy, so this is the "best > effort" we came up with. Or in other words, if someone MUST HAVE Maven > support for some pre-3.2.5 version, they will have to either live with an > older version of tooling (plugins) as well, that works with older Maven, > or use a phonebook to order some pizza :) > > What we typically do, is: > a- declare "minimum runtime maven prerequisite" -- today this is for ASF > Maven core plugins 3.2.5 (in maven-plugin POM this is > project/prerequisite/maven element) > b- declare "minimum maven dependencies" -- this is usually same as "minimum > runtime maven prerequisite" (these are the maven dependencies you build > against) > c- declare "minimum built time maven prerequisite" -- this is required > maven version to build the plugin (or project), this is good to keep up to > date, ie. I would use 3.6.3 or even 3.8.8 or so, and can be enforced using > enforcer (along with Java build time version and Java byte code versions). > d- strive to use up to date maven-plugin-plugin (and related dependencies, > like maven-plugin-annotations) > > An example of this above (note: this is not ASF Maven Core plugin, but is a > simple showcase as the plugin itself is simple. ASF Maven plugins have > quite a deep POM parent-child hierarchy): > a- > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L55-L57 > and > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L106 > b- > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155 > c- > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155 > and > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L233-L241 > d- > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L109 > > Moreover, all "maven dependencies" (those in groupID "org.apache.maven", > part of Maven) should be in "provided" scope (as they are provided by Maven > itself at plugin runtime. But a more recent maven-plugin-plugin (reason why > is recommended) will direct you, and warn if some scope is off. > > Finally, if you use plexus-utils, declare it explicitly, as starting with > Maven 3.9.x plexus-utils is NOT auto-injected (provided) in the plugin > classpath anymore. > > Something similar I attempted to jot down here: > https://cwiki.apache.org/confluence/display/MAVEN/Notes+For+Maven+3.9.x+Plugin+Developers > > Another page, maybe not directly for you (targets Maven devs, but has > useful information for plugin devs as well): > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup > > All this above is for Maven plugins "in general", nothing in relation with > "reporting", just a FYI. > > Now, this above is "ideal case", if things get more hairy (ie. plugin > reaches to some internals of Maven, maybe not even meant to be as Public > API, this may usually cause some breakage), solution MAY be to lift lower > end of "compatibility" from 3.2.5 to something like 3.6.3 or so, if > possible.... > > HTH > Tamas > > > > > >> On Mon, Mar 20, 2023 at 7:04 PM Ryan Heaton <r...@webcohesion.com> wrote: >> >> Hi. >> >> Apologies in advance if the dev list would have been a better place for >> this question. I maintain some Maven plugins for the Enunciate project >> <http://enunciate.webcohesion.com/> and wanted to update to the latest >> versions of the Maven API. I have one specific question, and then a more >> general question. >> >> My specific question is about the maven-reporting-api. Doing an artifact >> search revealed version 3.1.x, so I assumed that was still compatible with >> the latest Maven versions. But when I updated my plugin to use that API >> version it broke when using Maven 3.x.x: >> >> [WARNING] An issue has occurred with enunciate-maven-plugin:2.15.0:docs >>> report, skipping LinkageError Receiver class >>> com.webcohesion.enunciate.mojo.DocsMojo does not define or inherit an >>> implementation of the resolved method 'abstract void >>> generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface >>> org.apache.maven.reporting.MavenReport., please report an issue to Maven >>> dev team. >>> >> >> So do I just need to fix on maven-reporting-api version 3.0 and ignore the >> deprecation warnings for e.g. org.codehaus.doxia.sink.Sink? If >> maven-reporting-api 3.1.x is incompatible with Maven 3.x why wasn't it >> given a major version release? >> >> So now the more general question: how do I know which versions of artifacts >> are the latest versions that are compatible with Maven 3.x? >> >> I've got all these specific dependencies: >> >> - maven-plugin-api >> - maven-artifact >> - maven-compat >> - maven-filtering >> - maven-plugin-annotations >> - plexus-utils >> - plexus-interpolation >> - maven-reporting-api >> >> How do I know the most up-to-date version recipe? >> >> Thanks! >> >> -Ryan >>
