MailScanner version 4.65.3 andperl-MailTools-2.02-1.el4.rf HOWTO

[Gerard]

On Sunday December 09, 2007 at 12:26:12 (PM) Peter Farrow wrote:

> Gerard wrote:
> > On Sunday December 09, 2007 at 07:38:48 (AM) Randal, Phil wrote:
> >
> >   
> >> Half the problem is perl module authors who don't give a damn about
> >> backwards-compatibility.
> >>     
> >
> > I think that is being a bit harsh. In many cases maintaining 100% backwards
> > compatibility is not feasible. This becomes rapidly apparent when an update
> > deals with a security problem for instance. Most authors make allowances for
> > end users when possible; however, that is not always possible. Software
> > development is an on gong process. To expect it to simply sit idle while
> > end users catch up is ridiculous.
> >
> > A software developer makes a choice as to how he develops his product. An end
> > user has a choice as to whether or not he/she wishes to use said product. If
> > the end user declines to make his/her system compatible with the product they
> > are trying to utilize, then they have in fact made a conscious decision to not
> > use said product.
> >
> > If no users could maintain a system that was compatible with the authors
> > product, then a case could be make that the software author's requirements
> > were not reasonable. However; when the actual number of end users who are
> > affected  is minute, and mostly of their own conscious decision, blaming a
> > software author is ludicrous.
> >
> > By the way, I was not aware that 'perl module authors' were being reimbursed
> > for their efforts. Since they apparently are doing on their own dime, they can
> > pretty much do as they wish with their product. No one is excluded from
> > writing their own module and having it included in the Perl offerings.
> >
> > Just my own 2¢.

>  >>In many cases maintaining 100% backwards
> compatibility is not feasible.
> 
> I disagree, in cases such as libraries which are inherently, by design,  
> to be called from other software, backwards compatibility is ESSENTIAL.

It is only 'essential' if:

1) It is feasible to do so without incurring security or other incompatibility
problems.

2) If the end user is forced to upgrade his current program in such a manner
that it then requires an updated dependency. I have not seen any evidence that
anyone is being forced to update their version of MainScanner. Even if they
were, it would not make an iota of difference since it is possible to update
Perl, and thus eliminate the perceived problem. That is obviously incorrect
since other users are not encumbered by this problem.

I realize that I am not familiar with every OS available; however, I still have
not been given a solid reason why the updating of Perl, and if we are still
referring to Perl-5.6, that is an obsolete version to begin with, why the end
user cannot simply update Perl on their system also. I have updated Perl on my
FreeBSD system in the past without any problems.

> Making a library not backwards compatible is basically lazy and there is 
> no reason for it...you make everyone else work to modify the existing 
> code base rather make your library work as it did.

You are assuming that the original module worked perfectly and therefore the
author simply wanted to invest wasted time on attempting to improve it. I have
sen no proof of that anywhere. Actually, I am going to contact the author an
attempt to ascertain their reasons for updating the module and why it could
not be made backward compatibility for what appears to be a relatively small
group of users. If I actually get a reply, I will post it here.

> If you can't make it backwards compatible, write an extension library, 
> if your code is insecure fix it. but keep the way it works.

It works now, as evident by the users of it. It also works with MailScanner
just fine, assuming you are not attempting to use it with antiquated software.

> In many cases if you break compatibility in a library you just delay 
> (indefinitely or otherwise) its uptake and acceptance as we have seen on 
> this very list.

I totally disagree. The only way anything gets accomplished is by individuals
taking a lead. If everyone just  assumes an attitude that once something works,
leave it alone, we would still be living in caves. By your own account, why
should Julian continue to work on this project?  It already works, so leave it
alone. Why run the risk of improving it if it ultimately causes it to fail
with some obsolete software or , heavens forbid, actually causes an end user
to maintain their system in a proper and timely fashion.


-- 
Gerard