On 4/7/11 10:00 AM, sebb wrote: > 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. > I agree with Sebb and Stephen on this. There is nothing stopping us from experimenting with new code and even releasing it with a different package name and artifactId. Releasing unstable APIs in a [lang] release is not a good idea, IMO.
Why not just create a separate component called something like "lang-alpha", let it have its own artifactId, versioning, release cycle, etc. and as bits of it stabilize, incorporate them into [lang] itself? That provides the spirit of the /contrib "directory" without the jar hell risk and it does not force us to throw out our Commons versioning guidelines. This pattern could be useful in other components as well. Given that foo-alpha may depend on [foo] and it may be tied to a version of [foo], it seems a safe and effective way to experiment with new APIs would be to allow [foo-alpha] to make incompatible changes in .x releases (since the version numbering is essentially off by one .), so you get a release sequence that looks like, e.g. foo 2.0 foo-alpha 2.0 (may depend on foo 2.0) foo-alpha 2.1 "" (could have incompatibilities with foo-alpha 2.0 or even foo-2.0) ... foo-alpha 2.n "" foo 2.1 (adds some non-compatibility breaking stuff from U(foo-alpha 2.i)) foo-alpha 2.(n+1) ... foo 3.0 (adds wonderful new stuff from all previous foo-alphas and whatever makes it in) Or if that is too complicated, you could completely detach the version numbering of the two components. I think the idea of having a separate, releasable "child" of some kind that can break compatibility with its parent and earlier versions of itself is a good one. The setup I have described above is probably not the best, but we should be able to figure out how to do it and communicate what it means to users. Letting the child keep living with the parent makes me nervous. I know it may be easier to just make a room in the basement, but then you have to soundproof the floors, etc. Better to just spring for another artifactId ;) Phil >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
