Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of garydgregory@gmail.com
 designates 209.85.214.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALznzY4y1np-W8C4+OLBLxUH6_xoq5dCjOEnFxza92jNtOKmRQ@mail.gmail.com>
References: 
 <CAB917RLfxx3peR30HsM4dWQ04EXrzZ_KoPGZAiccd6oFjHd5Sg@mail.gmail.com>
	<CAPCjjnFvhLbyZvNoejaXSjUQzVay3BxHFn17XD+xArHOzZZMMQ@mail.gmail.com>
	<l34elo$20p$1@ger.gmane.org>
	<CACZkXPw-VtbDJD9Dzs5vo7_vbfSdeFsCpNZ4SHQ856tqj_yuyQ@mail.gmail.com>
	<CAEQx=xkK17thM2-4Z+6vkB9b8FKmBfezTf5dGmU8mHndm8ohuA@mail.gmail.com>
	<5256735D.8090507@douma.nu>
	<l35une$1d7$1@ger.gmane.org>
	<635E8419-B316-4E95-8390-45B9065EBC82@gmail.com>
	<52568ECB.6040608@douma.nu>
	<52569154.6000804@apache.org>
	<525693C2.2060409@douma.nu>
	<52569CA0.4010509@apache.org>
	<CALznzY4y1np-W8C4+OLBLxUH6_xoq5dCjOEnFxza92jNtOKmRQ@mail.gmail.com>
Date: Thu, 10 Oct 2013 09:47:03 -0400
Message-ID: 
 <CACZkXPzLzteA6A7fkqOuy6TBESnet0sJH6d8YGy5Cw4K1btEBw@mail.gmail.com>
Subject: Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 10, 2013 at 9:06 AM, James Carman
<james@carmanconsulting.com> wrote:
> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <ebourg@apache.org> wrote=
:
>>
>> I'm afraid this is more than a perceived issue, the plexus-container
>> example given by J=C3=B6rg is a very good one. Pushing drastically
>> incompatible versions to Maven Central is not a good service for the use=
rs.
>>
>> 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).

Gary

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


--=20
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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