On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests
before deploying code (besides testing the complete system thoroughly).
If you use RFB, you can access the GUI in headless mode. Also when a
debugger opens with a deprecation warning, the stack trace is written to
the log file, so you will be notified about the problem even when you
don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that
uses a package that contains popups deprecation warnings) I have big
chances of being bite by this problem. I concede, this could be avoided
by test-running every and whatnot package in the image but for a system
that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation
warning with proper description about what and how to update/change?
Levente
Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing
that some part of the application is waiting some user input.
At the end I expect that the maintainer of the package is the
*responsible* of test the application for the image I use, and not the
user of the package. That is what I do with magma on Pharo. I test and
fix the issues generated by the evolution of Pharo and then I release a
new ConfigurationOfMagma that the user can use without knowing that n
deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method)
without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated
but, again, I think that this promote the external packages not being
updated to the current pharo image.
Cheers
--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx
