I think the big benefit of deprecation as it is now is that it is less
sudden, and prompts user to help fix problems by sending patches.
Because the deprecation makes it really easy to do and check the right
thing, that should be common. OTOH, I got zero patches until today for
the RB deprecation issues, so maybe that theory can use some revision.

Daniel

Julian Fitzell <julian at beta4.com> wrote:
> Daniel Vainsencher wrote:
> > I used the SM version of the Refactoring Browser for all my development,
> > at whatever is the alpha version. It currently uses deprecated methods
> > (which can be proceeded, or patched individually, and might be fixed
> > soon collectively).
> 
> Ugh... speaking of which... it seems to me that a deprecated method 
> isn't really deprecated if it pops up a dialog and halts processing; it 
> might as well be removed.  It's not much better than getting a DNU 
> really (well, ok, you get a more descriptive error and you *can* 
> continue).  But couldn't we have it just output a message to the 
> Transcript that the message is deprecated and then continue normally? 
> It seems to me that the point of deprecation is that software continues 
> to work during a period of time where the developer can find the 
> deprecations and change them.
> 
> The current situation doesn't really seem to leave software using the 
> deprecated methods in a "usable" state.  Perhaps this would even be 
> worthy of one tiny last change to 3.6 before final?  Or perhaps I'm the 
> only one who sees it this way...
> 
> Julian
> 
> 
> -- 
> julian at beta4.com
> Beta4 Productions (http://www.beta4.com)