I'd like to second the opinion that deprecated still works (until removed), but is discouraged from use. I believe that is what Andrus intends, though, given previous API changes.
On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I guess my problem is that to me @deprecate means "it still works like > it used to, but it won't work in a future version and it's time for > you to change your code", but that's not what's going to happen here. > > That's why if we're not really @deprecating it but crippling it, then > I'd recommend removing it. Giving end-users the false-hope that > things are working as usual isn't very nice. > > You know the details of this particular situation better than I do, > though. If you don't think silently doing nothing will affect > expected program behavior, go for it. > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > To me, that sounded like you were going to change the behavior rather > > > than just mark the method as @deprecated. > > > > > > > I was planning to do both. Although we may decide to be gentle about it > and > > deprecate the method, but preserve the functionality (which will put a bit > > of extra maintenance burden on us). > > > > I am leaning towards the first option (deprecate and stop invoking), > > especially since the nature of the change results in enhanced data > > consistency, so there won't be any unpleasant surprises. > > > > Andrus > > > > >
