2014-10-16 13:48 GMT+02:00 sebb <seb...@gmail.com>: > On 16 October 2014 09:35, Thomas Vandahl <t...@apache.org> wrote: >> On 16.10.14 02:06, sebb wrote: >>> On 16 October 2014 00:47, Olivier Lamy <ol...@apache.org> wrote: >>>> Perso I don' get the point to use this version number at the end of >>>> the artifactId >>> >>> The idea is that if the package name has to be changed again, i.e. to >>> org.apache.commons.jcs2, then the artifactId would become commons-jcs2 >>> so that they agree with each other. >> >> I consider this rule a bit strict, to be frank. I'd like to think that >> the problem of a broken API could be solved differently (by deliberately >> renaming API classes for example) but i can live with it for now. > > Renaming API classes will break compatibility unless one keeps the old > classes as well. > > Creating new classes and deprecating the old ones is a valid strategy, > but if one ever wants to get rid of the deprecated classes, it is > necessary to make a complete break. > > It is essential that a given class name only appears in a single Maven > (groupId,artifactId) pair, otherwise jar hell may result.
+ version + type, having twice the same artifact with different versions is not correct > It is also essential that within a Maven pair, classes are not dropped > between versions (unless the class is not part of the public API) > otherwise there will be binary compatibility issues. > Main issue is it duplicates a bunch if binaries for free and most of users could use N+1 without being impacted. it means this rule is too strict. Best is to externalize removed binaries in a -compatibility jar like did maven. It avoids the binary duplication and allow to go ahead on main stream (IMHO). >> Bye, Thomas. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
