On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma <a...@douma.nu> wrote: > On 10/10/2013 03:47 PM, Gary Gregory wrote: >> >> On Thu, Oct 10, 2013 at 9:06 AM, James Carman >> <ja...@carmanconsulting.com> wrote: >>> >>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg <ebo...@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-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 > -- E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
