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