On Wed, Jun 6, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: > Aaron Stone wrote: >> On Wed, Jun 6, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: >> >>> Charles Marcus wrote: >>>> SiS could always simply be a config option... so if you don't want the >>>> overhead, don't enable it... >>> Better yet: don't add the new tables (when I publish them) and dbmail will >>> gracefully downgrade to the old/current behaviour. >> >> But let's avoid parallel code paths and database schemas wherever >> possible. > > There's this weird word called deprecation. There's actually very low > cost in maintaining the current message handling code for the time > being. Mark it as such, and leave it be. It's well isolated.
Yes, exactly, the cost is low *for the time being*. We need to transition to whatever new stuff we're going to do so that we can drop the old code after a major release or two. The cost to maintain it will increase as it becomes unused, and the likelihood of bit rot will be very high. >From a quick look at the SVN log, the auto_replies code was broken for 15 months. The responsible thing for me to do last month was probably not to fix the segfault that was reported, but to throw the code out entirely! I would be satisfied with an ERROR level message that logged, every time the daemon starts, "You are running DBMail version 2.4 using the 2.2 schema. You must the upgrade script as this schema will not be supported in the future." Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
