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. 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
