No worries, I welcome the feedback. The only possible drawback to hard-coding to a particular version is that we cannot test every single version between 2.s and 2.x each release - it would take weeks to do so (150-73 = 77 versions!). So, it is possible that an older version of the JS can acquire bugs later. This could only happen if there was a change in the server output for a service (like geocoding, directions, or GGeoXml) that was incompatible with the JS in that particular version. We wouldn't make these changes on purpose, and we consider them a bug if such things occur, but it has happened twice in my time here.
So, in conclusion, with a web API that's both client+server, you can never rely entirely on the API not changing, but you can get pretty close - and hardcoding to a version # is likely the closest you'll come. - pamela On Fri, Apr 3, 2009 at 11:52 AM, Tom NY <[email protected]> wrote: > > Thanks Pamela. As I said in the other thread, I'm not complaining but > just trying to come with ideas to help avoid another problem. > > I think hard-coding to a version is a very good solution. The current > version of 2.s was released over a year ago which means that > developers can limit their upgrades to quarterly, for example, and not > have to worry about being hurried into a new API release. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Maps-API?hl=en -~----------~----~----~----~------~----~------~--~---
