Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <87y3z8v2wk.fsf@v45346.1blu.de>
References: <87y3z8v2wk.fsf@v45346.1blu.de>
From: sebb <sebbaz@gmail.com>
Date: Thu, 22 Dec 2016 08:41:09 +0000
Message-ID: <CAOGo0VZ2QkNFPOJa0S99OEV+qnRg-Dbv-1VgdtkW2iHA0G52RQ@mail.gmail.com>
Subject: Re: [compress] nearing 1.13 release, backwards incompatible change(?)
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 22 Dec 2016 08:41:18 -0000

On 22 December 2016 at 07:28, Stefan Bodewig <bodewig@apache.org> wrote:
> Hi
>
> I've managed to build japicmp reports for COMPRESS, the full site of the
> current master is at
> http://stefan.samaflost.de/staging/commons-compress-1.13/
>
> If you look at
> http://stefan.samaflost.de/staging/commons-compress-1.13/japicmp-maven-plugin-report.html
> you'll see a few strange things. Some new methods and classes are
> flagged as binary incompatible because they throw checked
> exceptions. This seems to be japicmp, not a real issue with the code.

The report is really hard to read as the only marker is (*) or (!) or blank
Apart from spotting the markers, one has to remember which is which.

I could not find any BC issues.
However there are a few source incompatibilities.

Adding a thrown Exception does affect source compilation of calling
code, but exceptions are not part of method signatures so do not
affect BC.

> But there is one binary incompatible change (a serialization
> incompatibility): UnsupportedZipFeatureException has a new
> serialVersionUID. This is because it really changed its serialization
> from not being serializable at all to being serializable (the old code
> had non-transient non-serializable fields).
>
> I think this is acceptable.

It's not a BC issue ...
But in any case I think it would be OK.

However, does it really make sense to support serialization?
It can be a lot of work to get right, tends to make it hard to have
immutable classes, and is a source of security holes.

> Could you please look over the reports and at the current code base to
> determine whether there is anything that needs to get fixed before
> cutting a release?
>
> Thanks
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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