On 22 October 2013 20:55, Matt Benson <gudnabr...@gmail.com> wrote: > On Tue, Oct 22, 2013 at 2:49 PM, sebb <seb...@gmail.com> wrote: > >> On 21 October 2013 20:28, Henri Yandell <flame...@gmail.com> wrote: >> > 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? >> >> That would work for me. >> >> What would?
"indicate that we plan to remove this code in 4.0" > > >> > Hen >> >> --------------------------------------------------------------------- >> 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
