commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 13:47:03 GMT
On Thu, Oct 10, 2013 at 9:06 AM, James Carman
<> wrote:
> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <> wrote:
>> I'm afraid this is more than a perceived issue, the plexus-container
>> example given by Jörg is a very good one. Pushing drastically
>> incompatible versions to Maven Central is not a good service for the users.
>> I think my suggestion is a good compromise, otherwise the die-hard
>> compatibility defenders here will never agree to publish incompatible
>> artifacts to Maven Central.
> This gets back to my earlier comments on another thread.  We can't try
> to stupid-proof our code.  If our users want to do something stupid,
> we can't protect them from themselves.  If they want to "release" code
> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
> them.
>> I agree this is annoying, but this has to be balanced with the annoyance
>> of dealing with incompatible dependencies (for example, components
>> depending on different versions of BouncyCastle). It's easy to rename an
>> import in your code compared to fixing a jar hell situation.
> If a third-party library releases a version which points at one of our
> alpha releases and relies upon an API that they've been told may not
> be stable, then they need to fix it.  Again, we can boil the ocean
> trying to think up all the stupid things people can do with our
> software and try to code/process around it, but at the end of the day,
> you can't fix stupid.

Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.

Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message