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, On Jun 29, 7:44 am, GVIZ PM <[email protected]> wrote: > 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. > -- You received this message because you are subscribed to the Google Groups "Google Visualization 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-visualization-api?hl=en.
