> On 16 Jul 2015, at 15:56, Karthik Kambatla <ka...@cloudera.com> wrote: > > On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey <bus...@cloudera.com> wrote: > >> On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla <ka...@cloudera.com> >> wrote: >> >>> On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran <ste...@hortonworks.com> >>> wrote: >>> >>> >>>> -any change to the signature of an API, including exception types & >> text >>>> -changes to wire formats >>>> >>> >>> These two should hold for minor releases also, no? >>> >>> >> At the risk of derailing this thread, no definitely not. "any change" would >> include backwards compatible additions / changes. Using this stricter >> restriction is great for patch releases, since it means that a user can >> safely move onto a newer patch release with the assurance that if some >> regression should show up they can move back to an earlier patch release >> without risk that changes in their application since upgrading won't work >> due to reliance on an addition. >> > > I am not sure I understand the need for restriction for source and binary > backwards-compatible API changes.
Here's an example: YARN-3477, TimelineClientImpl swallows exceptions https://issues.apache.org/jira/browse/YARN-3477 I want to change it so that when retries time out, it rethrows the original exception, and convert InterruptedException to InterruptedIOException then throw These don't change the explicit binary signature of the code, but they do change what gets thrown on a timeout, as well as the text in the message. I'd rate that as a -1 for a 2.6.x patch, or 2.7.x, but happy to put into 2.8
