I'm okay with removing the @deprecated tag from the said methods. Maybe we can just add it as <strong>Note:</strong> to the main JavaDoc, or something like that?
2013/10/25 Matt Benson <gudnabr...@gmail.com> > Do we want to go with Sebastian's suggestion here, or discuss further? I > wouldn't call the matter resolved, and it does indeed look a bit irritating > to see deprecation warnings in [lang]'s *own* code. > > Matt > > > On Tue, Oct 22, 2013 at 3:00 PM, sebb <seb...@gmail.com> wrote: > > > 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 > > >> > > >> > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
