commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 14:06:26 GMT
On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <ate@douma.nu> wrote:
> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>
>> 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ö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).
>
>
> I state that an alpha release (which I gather you prefer above calling it
> milestones), by definition, cannot have a 'Compatibility' claim to begin
> with, hence cannot break one either.
>
> So, are you OK with alpha releases, which do NOT claim any stability nor
> compatibility?

Yes, an alpha is an anything goes release.

Whether or not it is in a special package is a different story :)

Gary

>
>
>>
>> Gary
>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>



-- 
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


Mime
View raw message