On Mon, Oct 21, 2013 at 7:29 AM, sebb <seb...@gmail.com> wrote:

> On 21 October 2013 11:52, Benedikt Ritter <benerit...@gmail.com> wrote:
> >
> >
> > Send from my mobile device
> >
> >> Am 21.10.2013 um 03:46 schrieb sebb <seb...@gmail.com>:
> >>
> >>> On 20 October 2013 15:03, Benedikt Ritter <brit...@apache.org> wrote:
> >>> I agree. If we don't deprecate it now, and agree to release the next
> major
> >>> version targeting Java 7, we would remove those methods without ever
> >>> mentioning it before.
> >>
> >> That's not how I see it working.
> >>
> >> I think the deprecations should be added once the code requires a
> >> minimum of Java 7.
> >> Later on, the deprecated methods are removed if required (they could be
> left).
> >>
> >> In any case, removal of the deprecated methods is not binary
> >> compatible, so new package/Maven coords are needed.
> >> In which case, it's not really a problem that the methods are not
> >> deprecated first.
> >> It would be sufficient to note the replacements in the release notes.
> >>
> >> Deprecation is only useful to users of a library if there is a
> >> replacement they can use.
> >
> > There is a replacement as Hen has pointed out. What you're saying is
> that the replacement has to be part of the library, right?
>
> Not necessarily, the replacement could be part of standard Java classes.
>
> But I don't think it's right to require users to migrate to a later
> version of Java than is required by the library itself in order to
> avoid the deprecation warning.
>
> And as I already wrote, it's important that deprecation warnings are
> removed (not suppressed) in the library itself.
> That is necessary to show that the deprecation makes sense.


What's your solution, Sebb, to indicate that we plan to remove this code in
4.0?

Hen

Reply via email to