Re: perl 5.005

[matt]

On Mon, 18 Jul 2005, Peter J. Holzer wrote:

 Is compatibility with perl 5.005 still desirable? We still have one mail
 server with RH 6.2 running qpsmtpd 0.26, and I'm unsure whether I should
 make qpsmtpd perl-5.005-compatible (currently it uses our in a couple
 of places and maybe a few other perl-5.6isms) or finally get the
 replacement machine up and running (actually, I know I really should do
 the latter :-)).

I'm all for dropping support of 5.5. Move up to 5.8.

Re: perl 5.005

[John Peacock]

[EMAIL PROTECTED] wrote:

I'm all for dropping support of 5.5. Move up to 5.8.



For a pure Perl module (I don't even think any of our dependencies 
require XS), if we can maintain compatibility without too much trouble, 
I think we should.  On the other hand


require 5.006001;

seems a reasonable compromise.

John

Re: perl 5.005

[Matt Sergeant]

On 19 Jul 2005, at 09:01, John Peacock wrote:


[EMAIL PROTECTED] wrote:

I'm all for dropping support of 5.5. Move up to 5.8.


For a pure Perl module (I don't even think any of our dependencies 
require XS), if we can maintain compatibility without too much 
trouble, I think we should.


There were things added after 5.5 such as easy lexical filehandles [ 
open(my $fh, $filename) ] that I just wouldn't want to give up now.


What I don't want to do is have us all have to maintain an old 5.6 
install just to test it there before every release.


Matt.

Re: perl 5.005

[John Peacock]

Matt Sergeant wrote:
What I don't want to do is have us all have to maintain an old 5.6 
install just to test it there before every release.


Since we have allows our() to creep in, apparently no one was testing 
5.005 anyways. ;-)


Since I plan on keeping version.pm compatible back as far as I can 
(currently 5.005), I tend to have multiple Perl versions installed on at 
least one machine.  We could say primarily developed using Perl 5.8.x 
but lightly tested using 5.6.x and I could be pressured to at least 
ensure that it still accepts mail prior to each release.


I'll have to remember why I installed 5.8.x on my Cobalt boxes instead 
of using the included 5.6.0 before I commit to anything.  If we do 
decide to cut off earlier Perl releases, by all means make it explicit 
with a 'require' line rather than just a documentation mention.


John

Re: perl 5.005

[Keith Ivey]

I'm currently running qpsmtpd under 5.6.1, but I haven't updated qpsmtpd 
in several weeks.  I'd favor maintaining 5.6 compatibility, since there 
are a lot of machines out there that came with 5.6 and haven't had their 
perls upgraded.  Not sure what the can't-do-without 5.8-isms are, though.


--
Keith C. Ivey [EMAIL PROTECTED]
Washington, DC

Make capabilities more core?

[Matt Sergeant]

Currently I think the only thing that uses the capabilities notes 
field is the new tls plugin. My suggestion is to make this not a notes 
field any more, but an integral part of the $transaction object.


The reason being that currently we have a horrible hoop jump with it 
being in notes. Things like this:


my @capabilities = $self-transaction-notes('capabilities')
? @{ $self-transaction-notes('capabilities') }
: ();

And this:

my $cap = $transaction-notes('capabilities');
$cap ||= [];
push @$cap, 'STARTTLS';
$transaction-notes('capabilities', $cap);

Which would be much easier if we could just say:

$transaction-add_capability('STARTTLS');

And:

  my @capabilities = $transaction-capabilities();

Any objections?

Re: Make capabilities more core?

[Ask Bjørn Hansen]

On Jul 19, 2005, at 14:19, Matt Sergeant wrote:


Any objections?


Go for it.


 - ask