FYI I'm planning on making the next release (1.51) be the last that
officially supports perl 5.6.
This is partly to make it easier to implement changes in future
releases that improve performance with threaded perls. This will benefit
ActiveState perl users, people using DBI with mod_perl2, and users
O/S distributions that ship perl pre-built with threads enabled.
Tim.
Tim,
Is this now going to be rescinded, in light of the rest of the thread
with Gisle?
Regards,
JEff
-----Original Message-----
From: Tim Bunce [mailto:Tim.Bunce@pobox.com]=20
Sent: Wednesday, January 25, 2006 7:03 AM
To: dbi-users@perl.org
Subject: Future versions of DBI to require perl >=3D 5.8
FYI I'm planning on making the next release (1.51) be the last that
officially supports perl 5.6.
This is partly to make it easier to implement changes in future
releases that improve performance with threaded perls. This will benefit
ActiveState perl users, people using DBI with mod_perl2, and users
O/S distributions that ship perl pre-built with threads enabled.
Tim.
On Fri, Jan 27, 2006 at 07:05:15AM -0500, Jeff Urlwin wrote:
> Tim,
>
> Is this now going to be rescinded, in light of the rest of the thread
> with Gisle?
Possibly. Though I've had emails from people thanking me for saying
this since, they say, that's the only way their employers will be
pushed into upgrading their perl.
Note that I said "officially support" not "will no longer work with".
I could no longer "officially support" perl 5.6 but that doesn't mean it
won't work with perl 5.6 :)
But since no one pays me for "official support" of the DBI it doesn't
make much difference ;-)
Tim.
> Regards,
>
> JEff
>
> -----Original Message-----
> From: Tim Bunce [mailto:Tim.Bunce@pobox.com]
> Sent: Wednesday, January 25, 2006 7:03 AM
> To: dbi-users@perl.org
> Subject: Future versions of DBI to require perl >= 5.8
>
> FYI I'm planning on making the next release (1.51) be the last that
> officially supports perl 5.6.
>
> This is partly to make it easier to implement changes in future
> releases that improve performance with threaded perls. This will benefit
> ActiveState perl users, people using DBI with mod_perl2, and users
> O/S distributions that ship perl pre-built with threads enabled.
>
> Tim.
At 12:03 PM +0000 1/25/06, Tim Bunce wrote:
>FYI I'm planning on making the next release (1.51) be the last that
>officially supports perl 5.6.
>
>This is partly to make it easier to implement changes in future
>releases that improve performance with threaded perls. This will benefit
>ActiveState perl users, people using DBI with mod_perl2, and users
>O/S distributions that ship perl pre-built with threads enabled.
>
>Tim.
I have no problem with that (and in fact suggested so a year ago).
Moreover, I suggest you go a bit further and say that 5.8.1/5.008001
is the minimum version, rather than 5.8.0; no one should actually be
using 5.8.0 given all the bugs it has, and the 5.8.1 delta fixed more
than any subsequent release, I think.
Moreover, with this move, you can count on Perl supporting Unicode 4,
rather than just 3.2 (in 5.8.0).
As far as how this affects people using system perl, I can speak at
least for Mac OS X that the first version bundling 5.8.x, Panther,
bundled 5.8.1 (rc3), so something requiring 5.8.1 will agree to run
on it.
I currently use 5.8.1 as the declared minimum in my modules.
-- Darren Duncan
On Fri, 27 Jan 2006 14:20:31 -0800, Darren Duncan wrote:
Hi Darren
> Moreover, I suggest you go a bit further and say that
> 5.8.1/5.008001 is the minimum version, rather than 5.8.0; no one
> should actually be using 5.8.0 given all the bugs it has, and the
> 5.8.1 delta fixed more than any subsequent release, I think.
This is a bit trickier than it seems at first. Where I work - Monash Uni in=
Melbourne - the nature of the contracts with Red Hat suggest, AFAICT, that=
5.8.0
will be with us indefinitely :-(. The standard but simplistic reply, install=
your own version of Perl, has of course long term maintenance problems of=
its
own, even if it were possible. So I'll be sticking with the DBI compiled by=
the
sys admin...
--
Cheers
Ron Savage, ron@savage.net.au on 28/01/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
At 10:51 AM +1100 1/28/06, Ron Savage wrote:
>On Fri, 27 Jan 2006 14:20:31 -0800, Darren Duncan wrote:
> > Moreover, I suggest you go a bit further and say that
>> 5.8.1/5.008001 is the minimum version, rather than 5.8.0; no one
>> should actually be using 5.8.0 given all the bugs it has, and the
>> 5.8.1 delta fixed more than any subsequent release, I think.
>
>This is a bit trickier than it seems at first. Where I work - Monash Uni in
>Melbourne - the nature of the contracts with Red Hat suggest,
>AFAICT, that 5.8.0
>will be with us indefinitely :-(. The standard but simplistic reply, install
>your own version of Perl, has of course long term maintenance problems of its
>own, even if it were possible. So I'll be sticking with the DBI
>compiled by the
>sys admin...
Yes, and people could say that about other specific versions too.
I also don't see why the Red Hat supplied distro can't be more up to
date; in fact, I would expect any ongoing contract with them to
include furnishment of up to date distros.
Even if you can't move, its not like 5.8 is becoming a hard
dependency, rather just a soft dependency, as I recall.
-- Darren Duncan
On 1/27/06, Darren Duncan
[snip]
> Even if you can't move, its not like 5.8 is becoming a hard
> dependency, rather just a soft dependency, as I recall.
The minute Tim writes a piece of code with a construct that is new to
5.8 because
a) its cool
b) he can
c) its probably more effecient
that soft dependency gets real hard. If he says he's not supporting
5.6 then you cannot assume it will just work anyway.
--
Matthew O. Persico
On Fri, 27 Jan 2006 18:36:55 -0800, Darren Duncan wrote:
Hi Darren
> Yes, and people could say that about other specific versions too.
Fair enough.
> I also don't see why the Red Hat supplied distro can't be more up
> to date; in fact, I would expect any ongoing contract with them to
> include furnishment of up to date distros.
In a perfect world, they might condescend to upgrade, but then, in a perfect=
world (or even in the real one) you wouldn't be using Red Hat anyway, you'd=
be
using OpenBSD, right :-)))?
--
Cheers
Ron Savage, ron@savage.net.au on 28/01/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
Matthew Persico wrote:
> On 1/27/06, Darren Duncan
>
> [snip]
>
>> Even if you can't move, its not like 5.8 is becoming a hard
>> dependency, rather just a soft dependency, as I recall.
>
> The minute Tim writes a piece of code with a construct that is new to
> 5.8 because
> a) its cool
> b) he can
> c) its probably more effecient
>
> that soft dependency gets real hard. If he says he's not supporting
> 5.6 then you cannot assume it will just work anyway.
>
> --
> Matthew O. Persico
Yes but you have to cut the tether sometime.
Robert
--CXFpZVxO6m2Ol4tQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2006-01-28 10:51:54 +1100, Ron Savage wrote:
> On Fri, 27 Jan 2006 14:20:31 -0800, Darren Duncan wrote:
> > Moreover, I suggest you go a bit further and say that
> > 5.8.1/5.008001 is the minimum version, rather than 5.8.0; no one
> > should actually be using 5.8.0 given all the bugs it has, and the
> > 5.8.1 delta fixed more than any subsequent release, I think.
>=20
> This is a bit trickier than it seems at first. Where I work - Monash Uni =
in
> Melbourne - the nature of the contracts with Red Hat suggest, AFAICT, tha=
t 5.8.0
> will be with us indefinitely :-(.
Just for the record:
Redhat EL 2.1 perl 5.6.1 supported until May 2009
Redhat EL 3 perl 5.8.0 supported until Oct 2010
I guess the situation for SLES is similar.
So, if Tim wants to support those sysadmins who run distributions as
long as they are supported, he will have to support 5.6.1 for at least 3
more years.
(but then I guess those sysadmins will also use the DBI bundled with
their distribution, so that will not really be an issue, unless specific
DBDs require a newer DBI)
On a related note, I recently ran into some strange issues with
perl/DBI/DBD::Oracle on a RHEL3 box, which I "solved" by installing a
current version of perl into /usr/local. I didn't investigate the matter
in more detail, so I don't know where the problem really was, but it is
possible that DBD::Oracle on RHEL 3 (i.e., perl 5.8.0, DBI 1.32) is
already broken.
> The standard but simplistic reply, install your own version of Perl,
> has of course long term maintenance problems of its own, even if it
> were possible. So I'll be sticking with the DBI compiled by the sys
> admin...
I am the sysadmin :-)
I try to stick to vendor-supplied packages as long as possible. But as
the host ages, I find that I have to compile more and more packages
myself. So most of my hosts now have a /usr/local/bin/perl and some
subset of CPAN under /usr/local/lib/perl5.
hp
--=20
_ | Peter J. Holzer | If I wanted to be "academically correct",
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | hjp@wsr.ac.at | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
--CXFpZVxO6m2Ol4tQ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQDQAwUBQ93+yVLjemazOuKpAQFvzwXRAWU+UGG3i20Y9+QVcmPXxLGWWkPB lINE
ZZEIywWMjoo80KMYtqvmfpnhfSJxR2ia8WoQbNya2zoVzn5RQpHYesnbv3Ag omy+
omFzmFsoT4M5RjTcEcytJh+BbpRRj7/HN7X0WMojkDYbLy+4gOvJHrvVwz8F ZswP
G1W4HWdvI0E+yxbUGt8D4ClmgDuOqAcXqJc4sfEnwN5bdHphCEf+j03lMNEW xzCJ
PoS2SKR5QVQ13+MLrVCVaui4kA==
=CYd9
-----END PGP SIGNATURE-----
--CXFpZVxO6m2Ol4tQ--
On Mon, 30 Jan 2006 12:55:53 +0100, Peter J. Holzer wrote:
Hi Peter
> Redhat EL 2.1 perl 5.6.1 supported until May 2009
> Redhat EL 3 perl 5.8.0 supported until Oct 2010
Oh. I didn't know that. Thanx.
> So, if Tim wants to support those sysadmins who run distributions
> as long as they are supported, he will have to support 5.6.1 for at
> least 3 more years.
But this begs the question: What's wrong with the current level of support?
That is, even if DBI is updated, people aren't forced to install the=
upgrade,
are they? In every case, they /choose/ to upgrade or not, and each course of=
action has its own consequences :-).
--
Cheers
Ron Savage, ron@savage.net.au on 31/01/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
--3MHXEHrrXKLGx71o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2006-01-31 09:40:32 +1100, Ron Savage wrote:
> On Mon, 30 Jan 2006 12:55:53 +0100, Peter J. Holzer wrote:
> > Redhat EL 2.1 perl 5.6.1 supported until May 2009
> > Redhat EL 3 perl 5.8.0 supported until Oct 2010
>=20
> Oh. I didn't know that. Thanx.
>=20
> > So, if Tim wants to support those sysadmins who run distributions
> > as long as they are supported, he will have to support 5.6.1 for at
> > least 3 more years.
>=20
> But this begs the question: What's wrong with the current level of suppor=
t?
>=20
> That is, even if DBI is updated, people aren't forced to install the upgr=
ade,
> are they? In every case, they /choose/ to upgrade or not, and each course=
of
> action has its own consequences :-).
Normally, don't think this is a problem. Machines with an old
distribution are usually stable: They have been installed years ago,
they are doing their job, and there isn't much reason to change anything
except for the occational security or bug fix. So it doesn't matter
that DBI 1.51 needs perl 5.8.1 or whatever, because they have already
installed DBI 1.18 and they aren't going to upgrade it.
There are two exceptions:
* Some shops have a "all servers must have the same version of the same
OS" policy. So they may have settled on Redhat EL 2.1 when it was new
and they will continue to install new servers with Redhat EL 2.1 until
2008, when they will upgrade all servers to RHEL 7 (or whatever will
be current then). So for new applications, they may find that they
need a recent version of DBD::foo, which in turn needs a newer version
of DBI which needs a newer version of perl.
* Occationally, a bug or security hole needs to be fixed and backporting
the fix to a very old version is too much effort, so the affected
software needs to upgraded to the current version: Then you have the
same dependency chain as above.
I do agree that these problems are the problems of the sysadmins (and
occationally the programmer), and should not unduly hinder the
development of DBI. I consider it reasonable if a specific version of a
perl module requires a version of perl which is not more than 2.5 resp.
3.5 years[0] older than the module itself. So if Tim wants to require
perl 5.8.0 or even 5.8.1 for the next release of DBI, I say go ahead!
hp
[0] perl 5.8.0 was released on 18 July 2002 (hey, that was my 35th
birthday :-).
perl 5.8.1 was released on 25 Sept 2003.
--=20
_ | Peter J. Holzer | If I wanted to be "academically correct",
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | hjp@wsr.ac.at | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
--3MHXEHrrXKLGx71o
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iQDQAwUBQ99OuVLjemazOuKpAQHymAXUC8LqEDaWQ/BOLmGv5udf5lKyyT3o UgAc
+2oNv6FQg76i1hwioG1/vLZyLbFI5FYn4A3KOYru9qEWcmUvplDkNEnqnuW4 63Ih
6bDUwnwQIoLIt/pwdAMua+2ACwXIbgXwDBvKi0akV2ochXMHN3wyQjdLpywW rq1c
7U7CLxHxrSVTYTApr6ufyH8PxJHWeVNLYrV7HF3Zop/+I8X4Xn1wSm+sTBWc FuTh
hr0UMfA2rqYi4hseg6aho783NQ==
=MbqD
-----END PGP SIGNATURE-----
--3MHXEHrrXKLGx71o--