Actually I was going to do the opposite, but since we've set the
backwards compatibility bar for ourselves pretty high in the past, I
guess I am persuaded to go with deprecated-but-don't-cripple approach.
I guess that means also putting a deprecation note in the Modeler next
to refresh checkbox.
Andrus
On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
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
