The Google Chart Tools team has pushed a new release candidate: September 7, 2011

[ChartALot]

We have pushed a new release candidate (RC).

This RC is mainly aimed at bug fixes. Please pay special attention to the warning bellow, as we drop / change our support for some undocumented data-table structures.

Moreover, we created a new mailing list, google-chart-tools-announcements, which will be used only for announcements such as that.

Candidate release date: September 7

Anticipated production release date: September 14

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.

The Google Chart Tools team.

--------------------------------------------

WARNING: YOUR CHARTS MIGHT BREAK!

If you are using corechart charts with data tables whose first column is of type data/datetime/timeofday, your charts might break. Such data tables were never supported neither documented. We're now in the process of formally supporting them in the upcoming release, so we changed how they are handled:

• For the charts listed below, you MUST NOT use such data tables. Doing so will result in an error message. The type of the first column MUST be 'string', as documented. You can convert an incompliant data table to a compliant data table by using a DataView that converts the first column to a string. Seehere. For example, pass {calc: function(data, row) { return data.getFormattedValue(row, 0); }, type:'string'} to DataView.setColumns().
• PieChart
• BarChart
• ColumnChart
• CandlestickChart
• ComboChart where some of its series are of type 'bars'
• For the charts listed below, you MAY use such data tables, but the chart behavior in these cases changes. If you're not fond of the new behavior, you can return to the old behavior by using the above technique to convert the type of first data table column to 'string'.
• LineChart
• AreaChart
• ComboChart whose all series are of type 'line' or 'area'

You're strongly encouraged to test your charts with version 1.1 (RC) and change your code if necessary.

[NA]

I don't understand.

Are you saying that you never supported plotting data vs time?

Plotting data vs time is *extremely* common (I can't believe I even
have to type this out). Your current charts do this just fine,
without any problems. There is no reason to change that. Why would
you put in a change to break that? There's no reason not to have
dates with bar, column, or candlestick charts. In fact, using strings
is odd - their sorting properties aren't the same as for dates, which
makes handling things like axis direction awkward.

We plot data vs time in nearly all of our charts. If you break this
functionality, you will essentially have killed our company. The
sheer number of charts and graphs we will need to go through to check,
adjust, and hack around for this change is overwhelming; we just can't
do it before your release. Our application will break, and we won't
be able to do anything for our clients in any reasonable amount of
time.

Please do not do this.

[Jinji]

On Thu, Sep 8, 2011 at 4:46 PM, NA <nabee...@gmail.com> wrote:

I don't understand.

Are you saying that you never supported plotting data vs time?

Plotting data vs time is *extremely* common

I agree, and still, the fact is that it was never supported. See here, for example.

 

(I can't believe I even
have to type this out).  Your current charts do this just fine,
without any problems.  There is no reason to change that.  Why would
you put in a change to break that?  

I disagree about the "without any problems" parts. The support we intend to add (and doesn't exist at the moment) is important to many users.

There's no reason not to have
dates with bar, column, or candlestick charts.  In fact, using strings
is odd - their sorting properties aren't the same as for dates, which
makes handling things like axis direction awkward.

The email suggests a quick solution to converting these values to string using a DataView, so you won't have any sorting issues.

We plot data vs time in nearly all of our charts.  If you break this
functionality, you will essentially have killed our company.  The
sheer number of charts and graphs we will need to go through to check,
adjust, and hack around for this change is overwhelming; we just can't
do it before your release.  Our application will break, and we won't
be able to do anything for our clients in any reasonable amount of
time.

Please take a minute to look at the suggestions we made (using a DataView). It's a very easy and quick change. How many charts are we talking about?

Please do not do this.

--
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.

[Bill Kuker]

I can not imagine a more clear example of why Viz should use Google's
library version scheme!

Please let ME choose when to change from version 1 to version 2, and
if I am depending on bugs or ambiguity on version 1 please let me try
version 2 out in my dev environment, fix my code, commit it, QA it,
and ship it out to production.

I know I will upgrade sooner or later because I want bug fixes and new
features, but a page that specifies Visualization Version 1.2.3 should
NEVER break because of a change to the viz library, even if it relies
on a bug that is fixed in Version 1.2.4!

The google loader knows how to do this. It understands requesting a
specific revision, latest stable or latest development versions.

http://code.google.com/apis/loader/#versioning

On Sep 8, 4:16 am, ChartALot <charta...@google.com> wrote:
> We have pushed a new release candidate (RC).
>
>
>
> This RC is mainly aimed at bug fixes. Please pay special attention to the
> warning bellow, as we drop / change our support for some undocumented
> data-table structures.
>
> Moreover, we created a new mailing list,

> google-chart-tools-announcements<http://groups.google.com/group/google-chart-tools-announcements/subsc...>,

> which will be used only for announcements such as that.
>

>  *Candidate release date:* September 7
>
> > *Anticipated production release date:* September 14

>
> 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.
>
> The Google Chart Tools team.
> --------------------------------------------
>
> WARNING: YOUR CHARTS MIGHT BREAK!
>
> If you are using corechart charts with data tables whose first column is of
> type data/datetime/timeofday, your charts might break. Such data tables were
> never supported neither documented. We're now in the process of formally
> supporting them in the upcoming release, so we changed how they are handled:
>

>    - For the charts listed below, you MUST NOT use such data tables. Doing

>    so will result in an error message. The type of the first column MUST be
>    'string', as documented. You can convert an incompliant data table to a
>    compliant data table by using a DataView that converts the first column to a

>    string. Seehere<http://code.google.com/apis/chart/interactive/docs/reference.html#Dat...>.

>    For example, pass {calc: function(data, row) { return
>    data.getFormattedValue(row, 0); }, type:'string'} to
>    DataView.setColumns().

>       - PieChart
>       - BarChart
>       - ColumnChart
>       - CandlestickChart
>       - ComboChart where some of its series are of type 'bars'
>    - For the charts listed below, you MAY use such data tables, but the

>    chart behavior in these cases changes. If you're not fond of the new
>    behavior, you can return to the old behavior by using the above technique to
>    convert the type of first data table column to 'string'.

>       - LineChart
>       - AreaChart
>       - ComboChart whose all series are of type 'line' or 'area'

[NA]

> The email suggests a quick solution to converting these values to string
> using a DataView, so you won't have any sorting issues.

> Please take a minute to look at the suggestions we made (using a DataView).
> It's a very easy and quick change. How many charts are we talking about?

I read your suggestion about using DataViews. If it's that simple,
then why don't you modify the charts to automatically do that
conversion on their own? That way we wouldn't need to modify all of
our code. You would make the change in a single place, allowing us to
benefit from that, instead of requiring us to make that change in
multiple locations. Your change would be backwards compatible.

So if it's as simple as the workaround suggests, why not do that in
the core chart classes?

> I agree, and still, the fact is that it was never supported. See

But it works. I see no reason to break it now. If you're working on
a better change for the future, then keep this working now. Or
implement the workaround in the charts themselves, as I suggested
above.

> I disagree about the "without any problems" parts. The support we intend to
> add (and doesn't exist at the moment) is important to many users.

And the currently working functionality you are taking away is
important to many other users.

Again, I implore you to not do this. You are literally destroying the
faith many of us had in your products. The lack of version control is
a major problem, and radical changes to the way the charts work have
catastrophic effects on smaller companies that don't have the
resources to continually update their chart code everytime you put out
a non-backwards compatible release.

[Jinji]

On Thu, Sep 8, 2011 at 10:56 PM, NA <nabee...@gmail.com> wrote:

> The email suggests a quick solution to converting these values to string
> using a DataView, so you won't have any sorting issues.

> Please take a minute to look at the suggestions we made (using a DataView).
> It's a very easy and quick change. How many charts are we talking about?

I read your suggestion about using DataViews.  If it's that simple,
then why don't you modify the charts to automatically do that
conversion on their own?  That way we wouldn't need to modify all of
our code.  You would make the change in a single place, allowing us to
benefit from that, instead of requiring us to make that change in
multiple locations.  Your change would be backwards compatible.

So if it's as simple as the workaround suggests, why not do that in
the core chart classes?

This is what we do now...

But the issue here is not ease/difficulty of implementation. It's about API. This API (first column of type date/datetime/timeofday) is needed for a different functionality, and an important one. Was it possible to choose a different API for the new functionality? Yes, but clean coherent API as a major advantage. The pain is short term, while the gain is long term.

> I agree, and still, the fact is that it was never supported. See

But it works.  I see no reason to break it now.  If you're working on
a better change for the future, then keep this working now.  Or
implement the workaround in the charts themselves, as I suggested
above.

> I disagree about the "without any problems" parts. The support we intend to
> add (and doesn't exist at the moment) is important to many users.

And the currently working functionality you are taking away is
important to many other users.

We're not taking away any functionality, just restricting the API to achieve (to match the documentation).

Again, I implore you to not do this.  You are literally destroying the
faith many of us had in your products.  The lack of version control is
a major problem, and radical changes to the way the charts work have
catastrophic effects on smaller companies that don't have the
resources to continually update their chart code everytime you put out
a non-backwards compatible release.

We understand, and are sorry for the inconvenience. Really. But we have weighed the benefits to be larger than the damage.

[ChartALot]

Dear chart users.

Following user requests, we are postponing the change which we warn about above.

A new release candidate will be available soon (probably on Monday). It will maintain our undocumented support for  data/datetime/timeofday as first column in core charts. We will announce once the RC is out it and provide another week for testing it before it goes live.

As noted in other threads, we are actively perusing a solution to the versioning issues rised in the forum, but it may take a while until such a solution is in place. You are therefore encouraged to move forward and implement the changes requested above.

Regards,

ChartALot.