The Google Chart Tools team has pushed a new release candidate: June 27, 2011

67 views
Skip to first unread message

GVIZ PM

unread,
Jun 27, 2011, 5:50:32 PM6/27/11
to google-visua...@googlegroups.com
We have pushed a new release candidate (RC).

This RC is mainly aimed at improving rendering efficiency and adding functionality to the corechart and treemap packages.

Candidate release date: June 27
Anticipated production release date: July 5

If your system uses the Interactive Charts in Google Chart Tools (Visualization API) for commercial and / or important production purposes we recommend you test the RC and use the opportunity to provide feedback to us prior to the production release. If there are any issues, these can be communicated back to our team by replying to this message.

Michael Fink
Google Chart Tools

Csaba Balogh

unread,
Jun 27, 2011, 7:58:52 PM6/27/11
to google-visua...@googlegroups.com
Hello!
where can I found the new documentation?
regards,
Csaba

2011/6/27 GVIZ PM <the...@google.com>

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To post to this group, send email to google-visua...@googlegroups.com.
To unsubscribe from this group, send email to google-visualizati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en.

NA

unread,
Jun 27, 2011, 10:49:28 PM6/27/11
to Google Visualization API
So how do we access it? And are there release notes that tell us what
the new features are and what changes to expect?



On Jun 27, 5:50 pm, GVIZ PM <the...@google.com> wrote:
> We have pushed a new release candidate (RC).
>
>
>
> This RC is mainly aimed at improving rendering efficiency and
> adding functionality to the corechart and treemap packages.
>
>
>
> > *
> *
>
> > *Candidate release date:* June 27
> > *Anticipated production release date:* July 5

Charlie van de Kerkhof

unread,
Jun 28, 2011, 2:47:03 AM6/28/11
to Google Visualization API
Hi,
Can we use version 1.2 in our call loading the API?

Just let us know how we can test it.

Cheers!
- Charlie

On Jun 27, 11:50 pm, GVIZ PM <the...@google.com> wrote:
> We have pushed a new release candidate (RC).
>
>
>
> This RC is mainly aimed at improving rendering efficiency and
> adding functionality to the corechart and treemap packages.
>
>
>
> > *
> *
>
> > *Candidate release date:* June 27
> > *Anticipated production release date:* July 5

Jinji

unread,
Jun 28, 2011, 4:55:13 AM6/28/11
to google-visua...@googlegroups.com
There's no documentation yet and no release note. Those will be available when the release is pushed to 1.0. Testing the RC is meant for detecting regressions, not trying out new features.

Csaba Balogh

unread,
Jun 28, 2011, 5:23:01 AM6/28/11
to google-visua...@googlegroups.com
I tested It with TreeMap. It has a wider white selection rectangle on OnMouseOver instead of narrow black. But the functionality is correct. 
Good Work! I'm waiting for the documentation with the new features. 
Regards,
Csaba

2011/6/28 Jinji <ji...@google.com>

NA

unread,
Jun 28, 2011, 10:03:55 PM6/28/11
to Google Visualization API
I'm alarmed by something I read here and on the page you linked to.
There's a comment on that link that says:

" (Note that these numbers will not increase with future releases.)
"

and you said:

" Those will be available when the release is pushed to 1.0."

Does that mean new versions, when released, will still be accessed by
using a version of "1" in the google.load() call? I thought the whole
point of using a version in that method call was so that you could
stay with an older version until you were ready to move to a newer
one. This lets application developers protect their products by being
able to move to a new version only when they're ready. I thought that
Google was being really smart about this, similarly to how other API
developers (Yahoo included) name their APIs.

Can you clarify if new releases will get new version numbers? Or do
you overwrite old versions with new ones? I can't imagine it's the
latter, but those two comments seem to suggest it.




On Jun 28, 5:23 am, Csaba Balogh <szonj...@gmail.com> wrote:
> I tested It with TreeMap. It has a wider white selection rectangle on
> OnMouseOver instead of narrow black. But the functionality is correct.
> Good Work! I'm waiting for the documentation with the new features.
> Regards,
> Csaba
>
> 2011/6/28 Jinji <ji...@google.com>
>
>
>
>
>
>
>
> > You can test the RC using instructions here:
> >http://code.google.com/apis/chart/interactive/docs/release_notes.html...

Jinji

unread,
Jun 29, 2011, 7:40:40 AM6/29/11
to google-visua...@googlegroups.com
On Wed, Jun 29, 2011 at 5:03 AM, NA <nabee...@gmail.com> wrote:
I'm alarmed by something I read here and on the page you linked to.
There's a comment on that link that says:

 " (Note that these numbers will not increase with future releases.)
"

and you said:

 "  Those will be available when the release is pushed to 1.0."

Does that mean new versions, when released, will still be accessed by
using a version of "1" in the google.load() call?  

Yes.

I thought the whole
point of using a version in that method call was so that you could
stay with an older version until you were ready to move to a newer
one.  

At least for the Visualization API, the version numbers are meant to differentiate the stable version from the RC.

This lets application developers protect their products by being
able to move to a new version only when they're ready.  

This is not possible, sorry. We provide only one stable version at a time.

I thought that
Google was being really smart about this, similarly to how other API
developers (Yahoo included) name their APIs.

Can you clarify if new releases will get new version numbers?  Or do
you overwrite old versions with new ones? I can't imagine it's the
latter, but those two comments seem to suggest it.

The latter. This is how it's always been for the Visualization API.

GVIZ PM

unread,
Jun 29, 2011, 7:44:01 AM6/29/11
to google-visua...@googlegroups.com
We might consider introducing version numbers in the future but our current model is:
Announcing a release candidate (1.1) for testing regressions
Launching a new version (1.0) including all new features

This has the advantage that developers automatically adopt the newest version (including all bug fixes and new features).

Thanks for sharing your feedback.

On Wed, Jun 29, 2011 at 5:03 AM, NA <nabee...@gmail.com> wrote:



--
Michael Fink
Product Manager
Google Chart Tools

NA

unread,
Jun 29, 2011, 1:43:55 PM6/29/11
to Google Visualization API
Hi Michael,

Thanks for your and Jinji's comments. You said:

> This has the advantage that developers automatically adopt the newest
> version (including all bug fixes and new features).

Yes, but it also forces the update into production for everyone,
including non-developers! You guys are killing me ;)

Not all teams are big enough to be able to debug their apps on
Google's timeframe. This makes using Google's visualizations vs a
more stable product risky, especially for a small team that can't
choose to stop product development to retest the GVIZ components.

As a product manager, I'm sure you can appreciate that. As a product
manager myself, I don't want that to happen either.

Please consider using new release numbers for new versions.

In fact, it seems like it wouldn't be a big deal to do that for the
upcoming version.

thanks for the consideration,

asgallant

unread,
Jun 29, 2011, 3:45:25 PM6/29/11
to google-visua...@googlegroups.com
Personally, I like the way the Google libraries API handles versioning (http://code.google.com/apis/libraries/devguide.html#versioning); it just isn't used that way with the Viz API.  According to the spec:

google.load('visualization', '1', {packages: ['corechart']});

would load the most current version, whereas:

google.load('visualization', '1.6', {packages: ['corechart']});

would load version 1.6, regardless of what the current version is.  As The Charts Guy on my dev team, it falls on me to make sure that any update to the API doesn't break the charts on our site, which can be quite a time-consuming task.  Having a stable API version to draw from would lighten my workload considerably.

asgallant

unread,
Jun 29, 2011, 3:57:16 PM6/29/11
to google-visua...@googlegroups.com

NA

unread,
Jul 6, 2011, 7:56:08 PM7/6/11
to Google Visualization API
Did the release go out yet? I'm asking because I'm now seeing errors
that I haven't seen before in code that we haven't touched recently.
These errors just started towards EOB today June 6.





On Jun 27, 5:50 pm, GVIZ PM <the...@google.com> wrote:
> We have pushed a new release candidate (RC).
>
>
>
> This RC is mainly aimed at improving rendering efficiency and
> adding functionality to the corechart and treemap packages.
>
>
>
> > *
> *
>
> > *Candidate release date:* June 27
> > *Anticipated production release date:* July 5

Viz Kid

unread,
Jul 7, 2011, 2:18:03 AM7/7/11
to google-visua...@googlegroups.com

Hi

Due to some bugs found in the release candidate, we have pushed a new release candidate yesterday and if all goes well, we will push the release next week, approximately on July 12.
So as for your question, the released version 1.0 has not been changed in the last few days. If the issues persists for you, please send us more information (preferably in a different thread)

Best,
  Viz Kid

Roni Biran

unread,
Jul 7, 2011, 2:20:10 AM7/7/11
to google-visua...@googlegroups.com
Hi,

Can you elaborate on the new features/changes due for the new version? :-)

10x


Viz Kid

unread,
Jul 7, 2011, 2:24:13 AM7/7/11
to google-visua...@googlegroups.com

We are working on documenting the new features which would hopefully be ready once the release is out.

  Viz Kid

Roni Biran

unread,
Jul 7, 2011, 2:25:47 AM7/7/11
to google-visua...@googlegroups.com
Cool
10x


Reply all
Reply to author
Forward
0 new messages