On 7 April 2011 16:42, Henri Yandell <flame...@gmail.com> wrote: > On Thu, Apr 7, 2011 at 8:32 AM, Jochen Wiedmann > <jochen.wiedm...@gmail.com> wrote: >> On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell <flame...@gmail.com> wrote: >> >>> I think a separate jar would be lot less valuable - that basically >>> makes it a separate project/branch etc. Even if we mess around in >>> Maven to produce multiple jars, we're still create two separate >>> artifacts simply to deal with any tooling for binary compat checking >>> that don't have a filter. >>> >>> Am I missing some element of binary compatibility that would cause >>> havoc; or is this a case where the havoc it will cause is entirely >>> intended? i.e. "Here be dragons" will allow dragons. >> >> I'm not completely sure to understand what you are precisely >> proposing, but one thing is sure: If you start distributing it as part >> of a public release, then it will be used, whatever you name the >> package. And if that's the case, then I'd clearly bring up the >> question of binary compatibility. > > There is no question :)
There is a rhetorical question ... why do it? (i.e. don't). > The answer is "It's not compatible", the same way it would be for an > alpha (or beta if necessary) release. Yes, but such releases are in an independent jar that won't become a hard dependency, and won't become a dependency of a dependency. Or if it does, the perpetrator deserves all they get. On the principle of least surprise, one should never include unstable APIs in GA code. Suppose ABC makes use of the alpha code in a popular jar. Then along comes another incompatible version, and DEF likes it. It's then impossible to use jars from ABC and DEF in the same classpath without one of them breaking. [OSGI may come to the rescue here, but we should not force that on everyone] Now if you really insist on including alpha code in the release jar, then there is a way of maintaining binary compatibility - but I don't know whether you will like it ;-) That is, change the package name for the alpha code every time the API breaks binary compatibility. e.g. o.a.c.lang.alpha.rev1 => o.a.c.lang.alpha.rev2. You can then deprecate alpha.rev1. However, you cannot remove alpha.rev1 without breaking binary compatibility, so the lang jar will gradually fill up with cruft. > Hen > > --------------------------------------------------------------------- > 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
