On Thu, Oct 10, 2013 at 10:04 AM, James Carman <ja...@carmanconsulting.com> wrote: > I think the idea is that we don't break BC between an older full > version and a new alpha/milestone/rc/whatever, unless of course, the > new alpha/milestone/rc/whatever release is on a new major version. > For example, we can have API breaks between commons-foo-1.0 and > commons-foo-2.0-alpha. We can have API breaks between > commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2. We cannot have API > breaks between commons-foo-2.0 and commons-foo-2.1-alpha. How does > that sound (the concept not the choice of alpha)?
Sounds reasonable. Gary > > On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory <garydgreg...@gmail.com> 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). >> >> Gary >> >>> >>> --------------------------------------------------------------------- >>> 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 >> > > --------------------------------------------------------------------- > 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
