Re: annoying changes in 3.0
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. Well, of course you don't have to always do it. As in, always maintain the deprecaited feature. What you DO have to always do is announce that in release n+ 1 that feature X will be removed and replaced by feature Y, and that for the n1 intervening releases BOTH versions of the feature will be supported. This gives people time to come up on the new version using existing syntax, and find the problems with the new syntax, if any. If problems exist they can stay with the old feature, and hopefully in the following release, or a patch of the current release, the problems with the new feature will be fixed. But the trick here is that at least one or more releases will contain both features. This is different than saying feature X will be replaced at the next major release. We'll tell you what to use in its place in the release announcement for the next major release. 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. But also to be fair, even though you give people N releases with both features available to do the conversion, there are going to be some significant number of users that simply won't do the conversion until they are forced to, even though they had 3 releases in which they could have done it. Most though will have been more sensible, if the feature decommitment is promenently makrked in the release notes, and the replacement feature is also mentioned. Loren
Re: annoying changes in 3.0
On Tue, 11 Jan 2005, Loren Wilton wrote: But also to be fair, even though you give people N releases with both features available to do the conversion, there are going to be some significant number of users that simply won't do the conversion until they are forced to, even though they had 3 releases in which they could have done it. Having overlap for at least one revision allows seamless in-place upgrade. Having zero does not. -Dan
Re: annoying changes in 3.0
At 02:28 AM 1/12/2005, Dan Hollis wrote: But also to be fair, even though you give people N releases with both features available to do the conversion, there are going to be some significant number of users that simply won't do the conversion until they are forced to, even though they had 3 releases in which they could have done it. Having overlap for at least one revision allows seamless in-place upgrade. Having zero does not. No Dan, it does not allow a seamless in-place upgrade, unless you only ever upgrade once. If SA version N+1 supports commands from N, and your config file is in version N syntax, you can upgrade seamlessly, but as soon as N+2 comes out, you won't be able to upgrade seamlessly anymore. If you're at N+1's syntax, you can upgrade to N+2, but as soon as N+3 comes out, you've got to edit.. And so on. Unless there's some additional detail I'm missing, like an expectation that SA will actually fix your config files for you, I don't see how this offers seamless upgrades except in the short term.
Re: annoying changes in 3.0
--On Tuesday, January 11, 2005 9:36 PM -0800 Loren Wilton [EMAIL PROTECTED] wrote: But the trick here is that at least one or more releases will contain both features. This is different than saying feature X will be replaced at the next major release. We'll tell you what to use in its place in the release announcement for the next major release. Anyone following the betas would have seen this coming for a long time. And anyone who considers any piece of software to be mission-critical had better be following betas. There was a long cycle of release candidates when an admin could check for site issues before the release went gold. That's the whole point of having release candidates. The developers can't foresee every possible variation in how people use their product.
Re: annoying changes in 3.0
Ya, I don't get the whole thread. If one wants seamless upgrades and backwards compat for 10 years one should stick to windows, Solaris, AIX etc. Ya, right. My 1 cent for the week. Stuart Johnston wrote: Dan Hollis wrote: 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. I'm sorry, I know this is getting OT but why do people keep bringing up perl6 adoption? Perl6 hasn't even been released! Besides which, Perl6 will include a translator and a Perl5 compatibility mode. http://dev.perl.org/perl6/faq.html -- Michael H. Collins Admiral, Penguinista Navy http://linuxlink.com /\ASCII Ribbon Campaign \ / No HTML/RTF in email x No Word docs in email / \ Respect for open standards Take your laptop and yell out: Can a brother get a ip address?
Re: annoying changes in 3.0
On Mon, 10 Jan 2005, Simon Byrnand wrote: I still havn't even considered looking at Apache 2.0 for example due to the major changes and the fact that things such as php weren't available for it for some time. (I hate to think what the issues with going to php 5 might be :) The same issues are hurting acceptance of perl6. Python isnt much better. All sorts of incompatibilty issues from 1.5 - 2.0 - 2.1 - 2.2 - 2.3 ... python apps breaking all over the place. No fun at all. -Dan
Re: annoying changes in 3.0
Loren Wilton [EMAIL PROTECTED] wrote on 01/07/2005 06:16:25 PM: Of course, when breaking old interfaces and adding new, the proper way (in the commercial software world, at least) is to have one release that supports both the old and new interfaces, so the users have a chance to change things at their own speed, rather than having to rebuild everything to use the new version. Didn't the docs for 2.6x, possibly even back at 2.55 tell people that it was being deprecated in a future release? I know I remember seeing it and changed my configs quite a while ago. Andy
Re: annoying changes in 3.0
At 06:33 PM 1/7/2005, Dan Hollis wrote: I guess it's just a difference in philosophy and attitude. On software projects I code, I leave backwards compatibility in if possible. Most of the time its very simple and never a kludge. I think our difference is not in philosophy, but in scale. I'm thinking 10 year maintenance timeframes, not the immediate release. Again, this philosophy of not supporting backwards compat where it is easy to do will just hurt in the long run, like it is hurting php, apache, perl, and other projects. Sidenote. http://news.netcraft.com/archives/web_server_survey.html sarcasm With over 68% market share, and increasing. Clearly Apache is hurting badly. /sarcasm I agree that yes, breaking change is sub-optimal. However, you also need to keep in perspective the costs of backward compatibility. 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. 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. 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?
Re: annoying changes in 3.0
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
Re: annoying changes in 3.0
Dan Hollis wrote: 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. I'm sorry, I know this is getting OT but why do people keep bringing up perl6 adoption? Perl6 hasn't even been released! Besides which, Perl6 will include a translator and a Perl5 compatibility mode. http://dev.perl.org/perl6/faq.html
Re: annoying changes in 3.0
At 18:06 7/01/2005, Dan Hollis wrote: On Thu, 6 Jan 2005, Matt Kettler wrote: At 07:27 PM 1/6/2005, Simon Byrnand wrote: - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) What was the logic behind this unnecessary change ? Flexibility. rewrite_header isn't just capable of rewiting the subject line. It can rewrite other headers too. I think he meant, why _remove_ the old syntax instead of supporting it _in addition to_ the new syntax? Yes, thats what I meant. I can't see any good reason not to support old syntax as backwards compatibility. It would ease migrating to 3.0.x a great deal for many sites to support backwards compatibility. Instead, stuff breaks. This is why people are so hesitant to move to php5, perl6 etc. spamassassin should not follow these examples. -Dan Some changes are an expectation of major new releases of software of course, but SpamAssassin seems to have had a few gratuitous ones over the past major couple of releases and a few silly little things like changing sa-learn --rebuild to sa-learn --sync etc I'm sure there were good reasons for it, but it still makes things difficult for people upgrading. I still havn't even considered looking at Apache 2.0 for example due to the major changes and the fact that things such as php weren't available for it for some time. (I hate to think what the issues with going to php 5 might be :) Regards, Simon
Re: annoying changes in 3.0
Of course, when breaking old interfaces and adding new, the proper way (in the commercial software world, at least) is to have one release that supports both the old and new interfaces, so the users have a chance to change things at their own speed, rather than having to rebuild everything to use the new version. Another unfortunately all too uncommon thing is, when breaking an interface and providing an exact equivalent with new syntax, is to provide a simple search-and-destroy tool that a user can run to fix all of the old files to uuse the new syntax, rather than forcing the user to do it by hand. After submitting a bug (that will be rejected) that the old stuff doesn't work, of course. Loren
Re: annoying changes in 3.0
I think changing the config options from release to release makes it very hard for sites larger than a couple users to upgrade, because you have to rely on every user updating their config when you upgrade. The UPGRADE file helps with this somewhat, but it's more geared for admins than users. -faisal
annoying changes in 3.0
Hi All, Just setting up SA 3.0.2 on a test server (to work towards upgrading our main server that runs 2.64) and have discovered a change that might seem innocent to the designers, but which is a PITA for us. According to UPGRADE: - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) What was the logic behind this unnecessary change ? In our case we have a global subject_tag setting in /etc/mail/spamassassin/local.cf but the per user .prefs files contain rewrite_subject 1 (or 0) depending on what the user selects through a web gui. (As one of a limited set of options they are allowed to configure) Now with 3.0, as far as I can see there is no longer a way to configure the actual subject string globally in the local.cf, but allow it to be turned on and off from a per user .prefs file ? Or have I missed something ? :( Looks like I'll have no choice but to remove the option from the web gui altogether, as having the actual subject string in every single .prefs file doesn't make changing it in future very practical... Regards, Simon
Re: annoying changes in 3.0
Simon Byrnand wrote: Hi All, Just setting up SA 3.0.2 on a test server (to work towards upgrading our main server that runs 2.64) and have discovered a change that might seem innocent to the designers, but which is a PITA for us. According to UPGRADE: - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) What was the logic behind this unnecessary change ? In our case we have a global subject_tag setting in /etc/mail/spamassassin/local.cf but the per user .prefs files contain rewrite_subject 1 (or 0) depending on what the user selects through a web gui. (As one of a limited set of options they are allowed to configure) Now with 3.0, as far as I can see there is no longer a way to configure the actual subject string globally in the local.cf, but allow it to be turned on and off from a per user .prefs file ? Or have I missed something ? :( Hi, rewrite_header Subject Will turn off the rewrite (ie setting it to nothing.) Regards, Rick
Re: annoying changes in 3.0
At 07:27 PM 1/6/2005, Simon Byrnand wrote: - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) What was the logic behind this unnecessary change ? Flexibility. rewrite_header isn't just capable of rewiting the subject line. It can rewrite other headers too. In our case we have a global subject_tag setting in /etc/mail/spamassassin/local.cf but the per user .prefs files contain rewrite_subject 1 (or 0) depending on what the user selects through a web gui. (As one of a limited set of options they are allowed to configure) Looks like I'll have no choice but to remove the option from the web gui altogether, as having the actual subject string in every single .prefs file doesn't make changing it in future very practical... Hmm, what about modifying the web GUI so the user can specify whatever subject tag they want? This way it's not up to you to enact (for whatever reason) some global change of the subject tag, instead each user can pick their own to suit their mailclient...
Re: annoying changes in 3.0
On Thu, 6 Jan 2005, Matt Kettler wrote: At 07:27 PM 1/6/2005, Simon Byrnand wrote: - The rewrite_subject and subject_tag configuration options were deprecated and are now removed. Instead, using rewrite_header Subject [your desired setting]. e.g. rewrite_subject 1 subject_tag SPAM(_SCORE_) becomes rewrite_header Subject SPAM(_SCORE_) What was the logic behind this unnecessary change ? Flexibility. rewrite_header isn't just capable of rewiting the subject line. It can rewrite other headers too. I think he meant, why _remove_ the old syntax instead of supporting it _in addition to_ the new syntax? I can't see any good reason not to support old syntax as backwards compatibility. It would ease migrating to 3.0.x a great deal for many sites to support backwards compatibility. Instead, stuff breaks. This is why people are so hesitant to move to php5, perl6 etc. spamassassin should not follow these examples. -Dan
Re: annoying changes in 3.0
--On Thursday, January 06, 2005 9:06 PM -0800 Dan Hollis [EMAIL PROTECTED] wrote: It would ease migrating to 3.0.x a great deal for many sites to support backwards compatibility. Instead, stuff breaks. This is why people are so hesitant to move to php5, perl6 etc. spamassassin should not follow these examples. So why wait until now, long after 3.0 is set in stone, to complain about this? The whole point of a major version change is to allow breaking compatibility. (The time spent supporting legacy stuff is time lost for creating new features.) You know because of that number change that things are going to break, so you start doing your homework early, before you're backed into fixing your own stuff to comply. At this point the horse is out of the barn, so the admins who weren't paying attention are naturally going to have to play catch-up. It's important to inform your PHB's that tracking the development of the products you support is a big part of your job. Mind you, I'm not arguing against the specific feature. I'm just saying that if a feature is important to you, don't assume that it's important to anyone else, or that someone else is watching your back for you.
Re: annoying changes in 3.0
At 12:06 AM 1/7/2005, Dan Hollis wrote: I think he meant, why _remove_ the old syntax instead of supporting it _in addition to_ the new syntax? I can't see any good reason not to support old syntax as backwards compatibility. Hmm, as a user that makes sense. As a programmer, it does not. There's nothing like adding backward compatibility kludges to add bugs to your code. Bugs mean extra work for the developers, work that could be better spent fighting spam. You'll find that most OSS packages will sacrifice backward compatibility in favor of maintainable code and fewer bugs to work around later. I know it's a bit of a pain, but the general OSS mindset of breaking backward compatibility is what allows most projects to progress forward. One or two of these hacks isn't so bad, but once you start down that road you eventually get bound up by having to maintain hundreds of hacks, kludges and other garbage in your code that users who still have config files from 20 years ago need to run their systems. The always maintain compatibility mindset of the windows world is convenient for users, but really slows down development progress in the long run, and in some cases completely prevents product improvements. It's a very bad mindset to be in. Even the windows world is starting to move away from it by obsoleting older versions of products. As for breakage, SA has a long history of doing this. This is by far not the first time.. ie: report_safe. The Linux kernel does it all the time to their low-level interfaces. Bind has done it to their zonefile formats.
Re: annoying changes in 3.0
On Fri, 7 Jan 2005, Matt Kettler wrote: Hmm, as a user that makes sense. As a programmer, it does not. There's nothing like adding backward compatibility kludges to add bugs to your code. Bugs mean extra work for the developers, work that could be better spent fighting spam. I guess it's just a difference in philosophy and attitude. On software projects I code, I leave backwards compatibility in if possible. Most of the time its very simple and never a kludge. Of course I design my code cleanly so backwards compat is rarely a kludge. I havent looked at SA code but I would hope it's written well enough that backwards compat for such a simple option isn't hard. If its too hard, then it would indicate a problem with the design. Again, this philosophy of not supporting backwards compat where it is easy to do will just hurt in the long run, like it is hurting php, apache, perl, and other projects. Often, not supporting backwards compat for old stuff means you will not get the critical mass and support required for users to embrace your new stuff. I hope SA doesnt embrace this philosophy. You want more users to be using the new versions, not less. -Dan
