Well, alphas still shouldn't break backward compatibility with a prior *full* release within a major version number. If they do, then it's a bug we need to address it. So, it's not really "anything goes." At least, that's how I'd think about it. Any new APIs are considered "volatile" and subject to change before the next full release.
On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
