Bug #89555 for Geo-Coder-Google: Geo-Coder-Google - JSON Version Requirement too high?

Wed Oct 16 11:26:17 2013 MRDVT [...] cpan.org - Ticket created

Subject:

Geo-Coder-Google - JSON Version Requirement too high?

Is there any reason that you require such a new version on JSON. I did not see it commented anywhere in documentation. Between, version 6 and 7 this was the change. - JSON::Syck => 0.10, + JSON => 2.27, CentOS ships with perl-JSON 2.15-5.el6 I'm going to test it out on that and see how it works. However, there has been a lot of change in the JSON library and I have no plans to tackle that mountain. Thanks, Mike mrdvt92

Wed Oct 16 18:05:45 2013 MRDVT [...] cpan.org - Correspondence added 20 min

On Wed Oct 16 11:26:17 2013, MRDVT wrote: Show quoted text

> Is there any reason that you require such a new version of JSON.

I updated the Makefile.PL to not require any particular JSON version and my install works for what I need. Show quoted text

> - JSON => 2.27, > + JSON => 0,

$ rpm -qa|grep JSON perl-JSON-2.15-5.el6.noarch perl-JSON-XS-2.27-2.el6.x86_64 I bet the intension was supposed to be JSON::XS => 2.27, mrdvt92

Wed Oct 16 18:10:01 2013 miyagawa [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #89555] Geo-Coder-Google - JSON Version Requirement too high?
Date:	Wed, 16 Oct 2013 15:09:29 -0700
To:	bug-Geo-Coder-Google [...] rt.cpan.org
From:	Tatsuhiko Miyagawa <miyagawa [...] gmail.com>

On Wed, Oct 16, 2013 at 8:26 AM, Michael R. Davis via RT <bug-Geo-Coder-Google@rt.cpan.org> wrote: Show quoted text

> Is there any reason that you require such a new version on JSON. I did not see it commented anywhere in documentation. Between, version 6 and 7 this was the change. > > - JSON::Syck => 0.10, > + JSON => 2.27,

Subject says too high, 2.27 was released 3 years ago and I don't see it as too high. Show quoted text

> CentOS ships with perl-JSON 2.15-5.el6

Nobody cares a particular version is shipped with whatever OS. Show quoted text

> I'm going to test it out on that and see how it works. However, there has been a lot of change in the JSON library and I have no plans to tackle that mountain.

a) I don't see many breaking changes in JSON 2.x b) If you're right and there *are* many changes, it's better to specify a minimum version that is supported, rather than leaving it to 0 and waiting for bugs to pop up because of JSON.pm being too old. -- Tatsuhiko Miyagawa

Wed Oct 16 18:10:01 2013 The RT System itself - Status changed from 'new' to 'open'

Mon Oct 27 17:51:11 2014 SREZIC [...] cpan.org - Correspondence added

On 2013-10-16 18:10:01, miyagawa@gmail.com wrote: [...] Show quoted text

> b) If you're right and there *are* many changes, it's better to > specify a minimum version that is supported, rather than leaving it to > 0 and waiting for bugs to pop up because of JSON.pm being too old.

No. Specifying some arbitrary minimum version is just wrong ("wrong" because of "arbitrary"). Only if you have hard facts about why a specific JSON version is causing problems, then a minimum version should be specified. And I won't talk about the possibility that newer versions of modules may have more bugs than older ones. Yes, this happens, and it's not uncommon. Regards, Slaven

Mon Oct 27 18:02:10 2014 miyagawa [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #89555] Geo-Coder-Google - JSON Version Requirement too high?
Date:	Mon, 27 Oct 2014 15:01:39 -0700
To:	bug-Geo-Coder-Google [...] rt.cpan.org
From:	Tatsuhiko Miyagawa <miyagawa [...] gmail.com>

Here's a fact: Newer versions of JSON has fewer bugs: see http://cpansearch.perl.org/src/MAKAMAKA/JSON-2.90/Changes Our support cost is not infinite to support ancient libraries or broken platforms. Also there's less chance of users having issues caused by older, buggy modules in the downstream, by specifying reasonably new version of the module. I'm fully aware that there's a chance that newer version of the modules have bugs and where users want to prevent upgrading modules before deploying. That's exactly why I wrote Carton, and there are similar tools such as Pinto or OrePAN2 to accomplish the similar goals. On Mon, Oct 27, 2014 at 2:51 PM, Slaven_Rezic via RT < bug-Geo-Coder-Google@rt.cpan.org> wrote: Show quoted text

> Queue: Geo-Coder-Google > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=89555 > > > On 2013-10-16 18:10:01, miyagawa@gmail.com wrote: > [...]

> > b) If you're right and there *are* many changes, it's better to > > specify a minimum version that is supported, rather than leaving it to > > 0 and waiting for bugs to pop up because of JSON.pm being too old.

> > No. Specifying some arbitrary minimum version is just wrong ("wrong" > because of "arbitrary"). Only if you have hard facts about why a specific > JSON version is causing problems, then a minimum version should be > specified. > > And I won't talk about the possibility that newer versions of modules may > have more bugs than older ones. Yes, this happens, and it's not uncommon. > > Regards, > Slaven >

-- Tatsuhiko Miyagawa

Tue Oct 28 14:28:39 2014 MRDVT [...] cpan.org - Correspondence added

Show quoted text

> Nobody cares a particular version is shipped with whatever OS.

This is an entirely incorrect and naive statement. If the OS ships with a version, then the OS supports the library. If I have to build an RPM from CPAN then I have to support the library. I never install from CPAN via Perl because in the long run that creates an unsupportable infrastructure. Unfortunately, since I have forked your package (just to change the JSON version), I now have to support it. I'd rather you or preferably Fedora take on that load. So, I'm stuck at perl-Geo-Coder-Google-0.11_01-1 with no plans to upgrade. This is all I'm using your package for. use Geo::Coder::Google::V3 0.11; $g=Geo::Coder::Google::V3->new(sensor=>$self->sensor, client=>$self->client, key=>$self->key); my $data=$g->geocode(location=>$string); my $json=$g->{'last_res'}->content; Mike

Tue May 26 21:59:16 2015 justin.d.hunter [...] gmail.com - Status changed from 'open' to 'rejected'