We apologize for introducing a regression bug in our JSON response for
the places collection and causing a disruption of your application.
The place elements should be part of the place array and not part of
the places associative array. The proper way to access a place in a
collection is using result[`places'][`place'][i]. We will fix this
bug in the next release of the API. Since the bug fix will restore
the original behavior, it will also break your client-side fix. We
suggest that you first look for a place array in the JSON response,
and if one is not returned, then use your client-side fix to find the
place elements.

Bug releases are expected to be backward-compatible, and not require a
version bump, as was the case here. We fixed a bug dealing with the
element names containing the URI and language values, and
unfortunately caused a new issue which was not covered by our
regression tests; we have since updated our test suite to ensure that
it does not recur.

While we cannot always share with you upcoming features and bug fixes,
we will add release notes to our API documentation at
http://developer.yahoo.com/geo/guide, and will post messages on
yws-geo informing users of new releases. We value your interest in
GeoPlanet, and want to provide the best support possible.

Eddie Babcock
Y! Geo

--- In yws-geo@yahoogroups.com, "Aral Balkan" <aral@...> wrote:
>
> Hi guys,
>
> Could you please _at least_ give us some notice when making an API
change that is not
> backwards compatible (or can someone please give me a feed I can
subscribe to to get
> notified of such changes if there is one?)
>
> I just realized that you removed the 'place' array from the JSON
object returned from
> places.q() calls (e.g., of form
http://where.yahooapis.com/v1/places.q('city
> name');count=0?format=json) and that the returned places object now
has the place
> indices as strings.
>
> This requires code to be changed from, for example,
result['places']['place'] to
> result['places'] and also requires that numeric indexed loops be
changed to use string
> indices.
>
> The net result was that it started causing 500 errors on my live app.
>
> Also, since you've got a version string in there, my expectation
would be that the API
> would _not_ change and such a change would be rolled out as /v2/ etc.
>
> Where can I find out about such API changes in the future before
they happen and are you
> planning on similar changes in the future?
>
> Thanks,
> Aral