[All] Source compatibility policy

[Pascal Schumacher <pa...@gmx.net>]

Hello,

what is our policy regarding source incompatible changes to our APIs?

Context: This commons io pull request: 
https://github.com/apache/commons-io/pull/54/files propose removing 
unnecessary throws declarations from public method signatures.

Thanks,

Pascal


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [All] Source compatibility policy

[Pascal Schumacher <pa...@gmx.net>]

Am 16.01.2018 um 00:06 schrieb Gary Gregory:
> For me, breaking source compatibility should be limited to what can be
> adjusted to in my sources very easily. I would also consider whether the
> breaks are for a cosmetic reasons for an actual bug fix. I would probably
> pass on cosmetic breaks within minor releases.
>
> In this case, an exception declared unnecessarily can make client code more
> cumbersome, but not always, if other parts of the code happen to throw the
> same exception.
>
> More important is binary compatibility, which we should not break within
> minor releases. What happens in this case to BC?

"Changes to the |throws| clause of methods or constructors do not break 
compatibility with pre-existing binaries; these clauses are checked only 
at compile time."

Source: 
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.21

Clirr does not report any errors or warnings.

Re: [All] Source compatibility policy

[Gary Gregory <ga...@gmail.com>]

For me, breaking source compatibility should be limited to what can be
adjusted to in my sources very easily. I would also consider whether the
breaks are for a cosmetic reasons for an actual bug fix. I would probably
pass on cosmetic breaks within minor releases.

In this case, an exception declared unnecessarily can make client code more
cumbersome, but not always, if other parts of the code happen to throw the
same exception.

More important is binary compatibility, which we should not break within
minor releases. What happens in this case to BC?

Gary

On Mon, Jan 15, 2018 at 2:26 PM, Pascal Schumacher <pascalschumacher@gmx.net
> wrote:

> Hello,
>
> what is our policy regarding source incompatible changes to our APIs?
>
> Context: This commons io pull request: https://github.com/apache/comm
> ons-io/pull/54/files propose removing unnecessary throws declarations
> from public method signatures.
>
> Thanks,
>
> Pascal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>