On Mon, 10 Jan 2005, Matt Kettler wrote: > <sarcasm> > With over 68% market share, and increasing. Clearly Apache is hurting badly. > </sarcasm>
Apache 2.0 and perl6 adoption is severely stunted because of major backwards compat issues. > Once you go that route, you must ALWAYS go that route, for every change, or > your efforts are more-or-less pointless. 90% backward compatibility isn't > really much better than 0%. If the user has to edit a config file to > upgrade, it's a pain. Making it impossible to upgrade without downtime is bad. With backwards compat you allow people to seamlessly upgrade, and migrate their changes on a live system. Without it, you force people to shutdown and convert their entire system in-place, before upgrading. That's bad. As for 90% not being better than 0%, that's patently false. And in the case of 2.64 -> 3.0, there's so few options to support for backwards compat that it seems silly to argue 90% vs 0%. > Also, once you decide to support an old option, you must support it for the > life of your project and never break it, otherwise all you've done is delay > the problem the user will eventually face, and maybe even make it worse as > they may become deeper entrenched in outdated syntax. See below. > By preserving backward compatibility with subject_tag, you save them from > having to fix one issue. What about the myriad of others? Should SA 3.0.4 > support all old syntax from 1.0 onward? >>>>> Nobody's asking for this. <<<<< You're constructing a strawman. spamassassin could adopt a policy of backwards compat over _one_ revision. As it is, the policy is backwards compat over _ZERO_ revisions. This hurts. -Dan
