Hi developers-

As some of you know, we release a new version of the API javascript
every 1 to 2 weeks. We have 3 version aliases - 2.x, 2, and 2.s. When
you request v2.x, you're getting the very-latest version - you
generally do this if you want to test bug fixes or try out newly added
features. When you request v2 (the recommended version alias), you're
getting the next-to-latest version. When you request v2.s, you're
getting the 'stable' version - meaning a version that doesn't have any
bad bugs but also won't be updated very frequently, so it's good for
developers who don't want to worry about newly introduced bugs as we
update each version. The currently served versions are 2.123 for 2.x,
2.122 for 2, and 2.73 for 2.s. When we find a version that doesn't
have any major bugs (unfortunately this takes a while to find), we'll
upgrade v2.s to a more recent version.

Because we'd like to focus our testing and efforts on supporting the
latest and greatest versions of the API - but also because we want to
make sure that there is a version that each developer can use that
fulfills their features but doesn't have app-effecting bugs - we've
decided to stop serving javascript versions less than 2.s. This means
that when a developer requests, for example, 2.72, they'll actually
get served 2.73. We've introduced the global constant G_API_VERSION to
make it easy for developers to see what version they're being served.
We're fairly certain that this automatic upgrade shouldn't break a
significant number of sites using the lower version numbers, as we've
checked both the logs and the logged bugs and found that there aren't
many sites using the lower versions, and there aren't many bugs in the
lower versions that aren't fixed in 2.73.

I know we haven't been clear about our policy in the past about
supporting old versions - mostly because we weren't sure if it was
feasibly to eternally support them or not. Now we've discussed it and
realized it will be in the long run better for developers and our team
to gradually fade out unnecessary versions and focus on more recent
ones.

The automatic upgrade will begin happening in a month (about 4
versions from now). Those of you who are using a version lower than
2.73 can change your code to using 2.s or 2 (or something in between)
to test if everything's still working. Post in the group if you need
help with the upgrade (with a link to your code, of course).

Thanks, and let me know if you have questions.

- pamela

On Aug 15, 8:04 am, "pamela (Google Employee)" <pamela....@gmail.com>
wrote:

Looking on a minimal map, one thing that's hard to avoid is the
"Terms of use" link. How about adding a title attribute with the
new G_API_VERSION to this link ?  Or tell me how I could do
that or something similar in a script. Another place to add this
info could be a normal map type control, instead of its "Show
street map" blurb it could say "Show street map (2.73)".

 Frank

Hi Frank (and others)-

I'd suggest using a bookmarklet to check the API version on a map. I
just put a link to one here:
http://gmaps-samples.googlecode.com/svn/trunk/versionchecker.html

Just right-click and do "Add Bookmark". I added it to my bookmarks
toolbar in Firefox for myself, so that I can click on it for any page
I'm on that uses the Maps API.

- pamela

On Mon, Aug 18, 2008 at 1:59 AM, frank

On Aug 19, 5:23 am, pamela wrote:

Brilliant, it shows 73 123 124 for ?v=2.s ?v=2 ?v=2.x respectively.

The favlet doesn't work in a Google gadget (iframe), thou.  Maybe
I should simply output __MODULE_ID__ and G_API_VERSION
to the JS error console.  As JS ignorant I only know that this is
possible, not how, but it's a start.. :-)

Thanks,

 Frank

Hi Frank-

You could do the following:

1) Use Firebug when debugging your gadget maps
2) Put these lines of code in your gadget map, somewhere after the API
has loaded in:
if(typeof console == "undefined"){
 var console = {log:function(){}}

console.log(G_API_VERSION);

That will display the version to your Firebug console, and should do
nothing in other browsers.

- pamela

On Sun, Aug 24, 2008 at 1:29 AM, frank

Done, I found also the videos... :-)  And a bug where
not handling a "null" getEarthInstance() result was a
bad idea.

Meanwhile I turned 2.x or 2 (whatever this actually
means) into a "user preference", if something breaks
users have an alternative.

I've also finally figured out how to use the AJAX
loader in combination with google.maps.LocalSearch.

Traps and pitfalls:  The google.load magic does not
yet work for 2.s (2.73).  Apparently.  The ChangeLog
does not state since when that is supposed to work.

Thanks
--
http://gmodules.com/ig/creator?synd=open&nocache=1&url=http://hmdmhdf...

Hi Frank-

Good point. Where would would be the best place to document from what
version upwards google.load works for?
(We have a standard for functions, but this isn't a function in our
own API).

- pamela

On Aug 29, 6:08 am, frank <hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com>
wrote:

On Aug 30, 4:08 am, "pamela (Google Employee)" <pamela....@gmail.com>
wrote:

How about inside the blue box at http://code.google.com/apis/maps/documentation/reference.html
and also at http://code.google.com/apis/ajax/documentation/#Versioning
-- which would seem a good place to mention similar restrictions with
other APIs.

Andrew

 [google.load and 2.s]

Yes, or in the note for Maps at the begin of the next chapter:
http://code.google.com/apis/ajax/documentation/#AvailableAPIs

| note: Version numbers between the current v2 and v2.s can also
| be specified. See the Maps API documentation for more details.

It is a one time thing, after a future 2.s works with the loader
the note can be trimmed.  IIRC google.load was introduced at the
time when hierarchical map type controls were added.

 Frank

-- This has been reposted so that the suggested guidelines post
appears at the top of the forum --

Hi developers-

As some of you know, we release a new version of the API javascript
every 1 to 2 weeks. We have 3 version aliases - 2.x, 2, and 2.s. When
you request v2.x, you're getting the very-latest version - you
generally do this if you want to test bug fixes or try out newly added
features. When you request v2 (the recommended version alias), you're
getting the next-to-latest version. When you request v2.s, you're
getting the 'stable' version - meaning a version that doesn't have any
bad bugs but also won't be updated very frequently, so it's good for
developers who don't want to worry about newly introduced bugs as we
update each version. The currently served versions are 2.123 for 2.x,
2.122 for 2, and 2.73 for 2.s. When we find a version that doesn't
have any major bugs (unfortunately this takes a while to find), we'll
upgrade v2.s to a more recent version.

Because we'd like to focus our testing and efforts on supporting the
latest and greatest versions of the API - but also because we want to
make sure that there is a version that each developer can use that
fulfills their features but doesn't have app-effecting bugs - we've
decided to stop serving javascript versions less than 2.s. This means
that when a developer requests, for example, 2.72, they'll actually
get served 2.73. We've introduced the global constant G_API_VERSION to
make it easy for developers to see what version they're being served.
We're fairly certain that this automatic upgrade shouldn't break a
significant number of sites using the lower version numbers, as we've
checked both the logs and the logged bugs and found that there aren't
many sites using the lower versions, and there aren't many bugs in the
lower versions that aren't fixed in 2.73.

I know we haven't been clear about our policy in the past about
supporting old versions - mostly because we weren't sure if it was
feasibly to eternally support them or not. Now we've discussed it and
realized it will be in the long run better for developers and our team
to gradually fade out unnecessary versions and focus on more recent
ones.

The automatic upgrade will begin happening in a month (about 4
versions from now). Those of you who are using a version lower than
2.73 can change your code to using 2.s or 2 (or something in between)
to test if everything's still working. Post in the group if you need
help with the upgrade (with a link to your code, of course).

Thanks, and let me know if you have questions.

- pamela

-- This has been reposted so that the suggested guidelines post
appears at the top of the forum --

Hi developers-

As some of you know, we release a new version of the API javascript
every 1 to 2 weeks. We have 3 version aliases - 2.x, 2, and 2.s. When
you request v2.x, you're getting the very-latest version - you
generally do this if you want to test bug fixes or try out newly added
features. When you request v2 (the recommended version alias), you're
getting the next-to-latest version. When you request v2.s, you're
getting the 'stable' version - meaning a version that doesn't have any
bad bugs but also won't be updated very frequently, so it's good for
developers who don't want to worry about newly introduced bugs as we
update each version. The currently served versions are 2.123 for 2.x,
2.122 for 2, and 2.73 for 2.s. When we find a version that doesn't
have any major bugs (unfortunately this takes a while to find), we'll
upgrade v2.s to a more recent version.

Because we'd like to focus our testing and efforts on supporting the
latest and greatest versions of the API - but also because we want to
make sure that there is a version that each developer can use that
fulfills their features but doesn't have app-effecting bugs - we've
decided to stop serving javascript versions less than 2.s. This means
that when a developer requests, for example, 2.72, they'll actually
get served 2.73. We've introduced the global constant G_API_VERSION to
make it easy for developers to see what version they're being served.
We're fairly certain that this automatic upgrade shouldn't break a
significant number of sites using the lower version numbers, as we've
checked both the logs and the logged bugs and found that there aren't
many sites using the lower versions, and there aren't many bugs in the
lower versions that aren't fixed in 2.73.

I know we haven't been clear about our policy in the past about
supporting old versions - mostly because we weren't sure if it was
feasibly to eternally support them or not. Now we've discussed it and
realized it will be in the long run better for developers and our team
to gradually fade out unnecessary versions and focus on more recent
ones.

The automatic upgrade will begin happening in a month (about 4
versions from now). Those of you who are using a version lower than
2.73 can change your code to using 2.s or 2 (or something in between)
to test if everything's still working. Post in the group if you need
help with the upgrade (with a link to your code, of course).

Thanks, and let me know if you have questions.

- pamela