commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [lang] alpha package
Date Thu, 07 Apr 2011 17:48:03 GMT
On 4/7/11 10:00 AM, sebb wrote:
> On 7 April 2011 16:42, Henri Yandell <flamefew@gmail.com> wrote:
>> On Thu, Apr 7, 2011 at 8:32 AM, Jochen Wiedmann
>> <jochen.wiedmann@gmail.com> wrote:
>>> On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell <flamefew@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message