Bug #88873 for DBD-XBase: "use 5.010" is unnecessary

Sat Sep 21 16:34:51 2013 SREZIC [...] cpan.org - Ticket created

Subject:

"use 5.010" is unnecessary

The DBD-XBase testsuite runs fine with perl 5.8.9 if both existing "use 5.010" statements are removed. So I assume that the version restriction can be removed. Regards, Slaven

Sat Sep 21 21:12:15 2013 JANPAZ [...] cpan.org - Correspondence added

The use 5.010 is a statement that I really don't have the capacity to take older perl versions into account anymore when developing and maintaining the module. Distributions packaging the module which have older perl versions are of course welcome to change/remove it in packaging time. But I as upstream would prefer to be able to set the minimal expected version.

Sat Sep 21 21:12:15 2013 The RT System itself - Status changed from 'new' to 'open'

Sat Sep 21 21:12:16 2013 JANPAZ [...] cpan.org - Status changed from 'open' to 'rejected'

Tue Dec 10 17:59:39 2013 SREZIC [...] cpan.org - Correspondence added

On 2013-09-21 21:12:15, JANPAZ wrote: Show quoted text

> The use 5.010 is a statement that I really don't have the capacity to > take older perl versions into account anymore when developing and > maintaining the module. > > Distributions packaging the module which have older perl versions are > of course welcome to change/remove it in packaging time. But I as > upstream would prefer to be able to set the minimal expected version.

There's CPAN Testers, there's travis-ci, so you don't have to test old Perl versions yourself. Just create a trial/development version of the distro, upload to CPAN, wait some days, and see if things are working for all OS and Perl versions. Regards, Slaven

Tue Dec 10 17:59:39 2013 SREZIC [...] cpan.org - Status changed from 'rejected' to 'open'

Tue Jun 03 03:11:24 2014 SREZIC [...] cpan.org - Correspondence added

On 2013-12-10 17:59:39, SREZIC wrote: Show quoted text

> On 2013-09-21 21:12:15, JANPAZ wrote:

> > The use 5.010 is a statement that I really don't have the capacity to > > take older perl versions into account anymore when developing and > > maintaining the module. > > > > Distributions packaging the module which have older perl versions are > > of course welcome to change/remove it in packaging time. But I as > > upstream would prefer to be able to set the minimal expected version.

> > > There's CPAN Testers, there's travis-ci, so you don't have to test old > Perl versions yourself. Just create a trial/development version of the > distro, upload to CPAN, wait some days, and see if things are working > for all OS and Perl versions.

Do you want to give it a try?

Tue Jun 03 05:10:50 2014 JANPAZ [...] cpan.org - Correspondence added

On Tue Jun 03 03:11:24 2014, SREZIC wrote: Show quoted text

> > Do you want to give it a try?

No, not really. I don't see the benefit of encouraging 5.8 in 2014. Do you have a specific use case when not supporting 5.8 breaks your deployments?

Thu Jun 05 02:31:59 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-06-03 05:10:50, JANPAZ wrote: Show quoted text

> On Tue Jun 03 03:11:24 2014, SREZIC wrote:

> > > > Do you want to give it a try?

> > No, not really. I don't see the benefit of encouraging 5.8 in 2014.

There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, and is supported until 2017 (the extended life phase, whatever this means, even lasts until 2020). A central university server I every now and then still login with Solaris 10 running has only 5.8.4 installed. I can imagine many other situations where older perls are installed. Show quoted text

> Do you have a specific use case when not supporting 5.8 breaks your > deployments?

My specific case is in https://github.com/eserte/bbbike/blob/master/.travis.yml I would like to get rid of the special handling for DBD::XBase, given that it's unnecessary (the newest DBD::XBase version works with 5.8.x). I find your attitude too pessimistic, and it's only focussed at one edge where things can break: a too old perl version. But what about too new perl versions? Why don't you put a 'die "Too new perl version" if $] > 5.014' in your Makefile.PL? And I bet you don't have the ability to test on all operating systems, so why don't you put a 'die "Not supported OS" if $^O eq "linux"'? Still the easiest solution is to remove the restriction, and if you find out that things are not working anymore with older perls, then herewith I offer you help. Regards, Slaven Regards, Slaven

Fri Jun 06 04:34:16 2014 JANPAZ [...] cpan.org - Correspondence added

On Thu Jun 05 02:31:59 2014, SREZIC wrote: Show quoted text

> > There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, > and is supported until 2017 (the extended life phase, whatever this > means, even lasts until 2020). A central university

And I maintain perl-DBD-XBase in EPEL 5 and there's perl-DBD-XBase-0.241-5.el5.noarch.rpm there. Show quoted text

> and then still login with Solaris 10 running has only 5.8.4 installed.

If perl came as package from Sun/Oracle, you probably should ask them to package DBD::XBase as native Solaris package as well. Show quoted text

> > Do you have a specific use case when not supporting 5.8 breaks your > > deployments?

> > My specific case is in > https://github.com/eserte/bbbike/blob/master/.travis.yml > I would like to get rid of the special handling for DBD::XBase, given > that it's unnecessary (the newest DBD::XBase version works with > 5.8.x).

Isn't the cleanest solution getting DBD::XBase packaged properly as .deb package so that it can be installed via apt-get, not via cpanm?

Sat Jun 14 05:20:20 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-06-06 04:34:16, JANPAZ wrote: Show quoted text

> On Thu Jun 05 02:31:59 2014, SREZIC wrote:

> > > > There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, > > and is supported until 2017 (the extended life phase, whatever this > > means, even lasts until 2020). A central university

> > And I maintain perl-DBD-XBase in EPEL 5 and there's perl-DBD-XBase- > 0.241-5.el5.noarch.rpm there.

What if the users need the newest DBD-XBase? Show quoted text

> > and then still login with Solaris 10 running has only 5.8.4 > > installed.

> > If perl came as package from Sun/Oracle, you probably should ask them > to package DBD::XBase as native Solaris package as well.

How likely is the success of such an attempt? I am just an unprivileged user on this system. I don't know anything about Solaris packages, the policy about requesting one at Oracle, and I would have to ask the sysadmin to install it... It's much more easier to install perl packages via CPAN.pm and setup a local::lib-like system. Anyway, even if somebody would build such a package for Solaris: he would have to patch the "use 5.010" away. Show quoted text

> > > Do you have a specific use case when not supporting 5.8 breaks your > > > deployments?

> > > > My specific case is in > > https://github.com/eserte/bbbike/blob/master/.travis.yml > > I would like to get rid of the special handling for DBD::XBase, given > > that it's unnecessary (the newest DBD::XBase version works with > > 5.8.x).

> > Isn't the cleanest solution getting DBD::XBase packaged properly as > .deb package so that it can be installed via apt-get, not via cpanm?

No, that's not how travis-ci works. Normally you don't specify any CPAN packages; everything is resolved and installed automatically by travis-ci, using normal perl/CPAN mechanisms (PREREQ_PM in Makefile.PL etc.). The list of CPAN modules explicitly listed in the .travis.yml is just for the exceptions. In an ideal world even the apt-get statements shouldn't be there but be replaced by Alien-* distributions. Anyway, all these complications wouldn't be necessary if just the "use 5.010" was removed...

Sun May 15 07:21:55 2016 SREZIC [...] cpan.org - Broken in 1.07 added