Tag Archives: release

Announcing v3.0 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v3.0 of the DCM/DFA Reporting and Trafficking API. Highlights of this major version release include: Although we strive to maintain backwards compatibility between releases, a number of enhancements in this release necessitated breaking changes to existing API workflows. Details of these and all other changes are covered in our release notes.

Deprecation and sunset reminder
In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.8, which will sunset on August 31st, 2018. After this date, any requests made against v2.8 will begin returning errors.

As a final reminder, API version 2.7 will be sunset on December 7th, 2017. To avoid an interruption in service, all users are required to migrate to a newer version before the sunset date.

Learn More
As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

Give it a try and let us know if you have any questions!
- Jonathon Imperiosi, DCM API Team

Introducing container-diff, a tool for quickly comparing container images

The Google Container Tools team originally built container-diff, a new project to help uncover differences between container images, to aid our own development with containers. We think it can be useful for anyone building containerized software, so we’re excited to release it as open source to the development community.

Containers and the Dockerfile format help make customization of an application’s runtime environment more approachable and easier to understand. While this is a great advantage of using containers in software development, a major drawback is that it can be hard to visualize what changes in a container image will result from a change in the respective Dockerfile. This can lead to bloated images and make tracking down issues difficult.

Imagine a scenario where a developer is working on an application, built on a runtime image maintained by a third-party. During development someone releases a new version of that base image with updated system packages. The developer rebuilds their application and picks up the latest version of the base image, and suddenly their application stops working; it depended on a previous version of one of the installed system packages, but which one? What version was it on before? With no currently existing tool to easily determine what changed between the two base image versions, this totally stalls development until the developer can track down the package version incompatibility.

Introducing container-diff

container-diff helps users investigate image changes by computing semantic diffs between images. What this means is that container-diff figures out on a low-level what data changed, and then combines this with an understanding of package manager information to output this information in a format that’s actually readable to users. The tool can find differences in system packages, language-level packages, and files in a container image.

Users can specify images in several formats - from local Docker daemon (using the prefix `daemon://` on the image path), a remote registry (using the prefix `remote://`), or a file in the .tar in the format exported by "docker save" command. You can also combine these formats to compute the diff between a local version of an image and a remote version. This can be useful when experimenting with new builds of an image that you might not be quite ready to push yet. container-diff supports image tarballs and the registry protocol natively, enabling it to run in environments without a Docker daemon.

Examples and Use Cases

Here is a basic Dockerfile that installs Python inside our Debian base image. Running container-diff on the base image and the new one with Python, users can see all the apt packages that were installed as dependencies of Python.


And below is a Dockerfile that inherits from our Python base runtime image, and then installs the mock and six packages inside of it. Running container-diff with the pip differ, users can see all the Python packages that have either been installed or changed as a result of this:


This can be especially useful when it’s unclear which packages might have been installed or changed incidentally as a result of dependency management of Python modules.

These are just a few examples. The tool currently has support for Python and Node.js packages installed via pip and npm, respectively, as well as comparison of image filesystems and Docker history. In the future, we’d like to see support added for additional runtime and language differs, including Java, Go, and Ruby. External contributions are welcome! For more information on contributing to container-diff, see this how-to guide.

Now that we’ve seen container-diff compare two images in action, it’s easy to imagine how the tool may be integrated into larger workflows to aid in development:
  • Changelog generation: Given container-diff’s capacity to facilitate investigation of filesystem and package modifications, it can do most of the heavy lifting in discerning changes for automatic changelog generation for new releases of an image.
  • Continuous integration: As part of a CI system, users can leverage container-diff to catch potentially breaking filesystem changes resulting from a Dockerfile change in their builds.
container-diff’s default output mode is “human-readable,” but also supports output to JSON, allowing for easy automated parsing and processing by users.

Single Image Analysis

In addition to comparing two images, container-diff has the ability to analyze a single image on its own. This can enable users to get a quick glance at information about an image, such as its system and language-level package installations and filesystem contents.

Let’s take a look at our Debian base image again. We can use the tool to easily view a list of all packages installed in the image, along with each one’s installed version and size:


We could use this to verify compatibility with an application we’re building, or maybe sort the packages by size in another one of our images and see which ones are taking up the most space.

For more information about this tool as well as a breakdown with examples, uses, and inner workings of the tool, please take a look at documentation on our GitHub page. Happy diffing!

Special thanks to Colette Torres and Abby Tisdale, our software engineering interns who helped build the tool from the ground up.

By Nick Kubala, Container Tools team


Announcing v201710 of the AdWords API

Today we’re announcing the release of AdWords API v201710. Here are some of the highlights for key AdWords features: If you’re using v201702 of the AdWords API, please note that it will be sunset on February 14, 2018. We encourage you to skip v201705 and v201708 and migrate straight to v201710. Please note that v201705 is deprecated. As mentioned in the recent blog post on the sunset and release schedule, both v201705 and v201708 will be sunset on March 28, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201710 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

AdWords API release and sunset schedule in 2018

In 2016 and 2017 we supported at least three versions of the AdWords API at any given time and four versions for a brief period after each new release. This led to older versions of the API supporting outdated functionality and lacking new features.

To improve your AdWords API experience, we will be updating our release schedule. Starting in March 2018 we will only support two releases concurrently at all times, and three releases for a brief period of four weeks, allowing developers to skip a version. To get us back on schedule, we will concurrently sunset v201705 and v201708 in March 2018. This brings the average lifespan of every API version released in 2018 down to nine months.

Additionally, we will be moving back to a schedule that releases three versions per year. The 2018 releases are scheduled for February, June and September.

As usual, make sure to check our deprecation schedule for more details on sunsets. If you have any questions about the new schedule, please reach out to us on the AdWords API forum or the Ads Developers Plus Page.
Herlen Zoljargal, AdWords API Team

Announcing v201708 of the AdWords API

Today we’re announcing the release of AdWords API v201708. Here are some of the highlights for key AdWords features: If you’re using v201609 of the AdWords API, please note that it will be sunset on October 2, 2017. We encourage you to skip v201702 and v201705 and migrate straight to v201708. Please note that v201702 is deprecated and will be sunset on February 14, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201708 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

Announcing v201705 of the AdWords API

Today we're announcing the release of AdWords API v201705. Here are the highlights:

If you're using v201607 of the AdWords API, please note that it will be sunseton June 27, 2017. We encourage you to skip v201609 and v201702 and migrate straight to v201705. If you're using v201609, be aware it's now marked deprecated and will be sunset on October 2, 2017.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201705 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

- Josh Radcliff on behalf of the AdWords API Team

Announcing v2.8 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v2.8 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include: Details of these and all other changes are covered in our release notes.

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.7, which will sunset on November 30th, 2017. After this date, any requests made against v2.7 will begin returning errors.

As a final reminder, API version 2.6 will be sunset on May 31st, 2017. To avoid an interruption in service, all users are required to migrate to a newer version before the sunset date.

Learn More

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

Give it a try and let us know if you have any questions!
- Jonathon Imperiosi, DCM API Team

Announcing v201702 of the AdWords API

Today we’re announcing the release of AdWords API v201702. Here are the highlights: If you’re using v201605 or v201607 of the AdWords API, please note that they are now deprecated and will be sunset on March 28, 2017 and June 27, 2017, respectively. We encourage you to skip v201609 and migrate straight to v201702.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201702 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

Updated release schedule for AdWords API

At the beginning of the year we announced an experimental bi-monthly release schedule for the AdWords API. Based on the results of this pilot and feedback from our developer community, we've decided on a quarterly release schedule for 2017. The 2017 API releases are scheduled for February, May, August and October.

We received positive feedback on increasing the release frequency from the previous three-times-a-year schedule. We also heard that the accompanying sunset schedule was an added burden for some API users. The quarterly release schedule aims to address this feedback. We will continue to monitor the release frequency and your feedback

On average, every AdWords API version released in 2017 will be available for approximately 10 months. One month after every major release, we will sunset the oldest outstanding API version. Similar to the 2016 schedule, we will support 3 releases concurrently at all times and 4 releases for a brief period of 4 weeks at a time to accommodate developers who want to skip two major releases.

As a reminder, v201605 is scheduled to sunset on February 28, 2017. We will post details about the release and sunset of other AdWords API versions on this blog and our developer site. If you have any questions, feel free to reach out to us on the AdWords API forum.
Herlen Zoljargal, AdWords API Team

Celebrating TensorFlow’s First Year

Originally posted on Google Research blog

It has been an eventful year since the Google Brain Team open-sourced TensorFlow to accelerate machine learning research and make technology work better for everyone. There has been an amazing amount of activity around the project: more than 480 people have contributed directly to TensorFlow, including Googlers, external researchers, independent programmers, students, and senior developers at other large companies. TensorFlow is now the most popular machine learning project on GitHub.


With more than 10,000 commits in just twelve months, we’ve made numerous performance improvements, added support for distributed training, brought TensorFlow to iOS and Raspberry Pi, and integrated TensorFlow with widely-used big data infrastructure. We’ve also made TensorFlow accessible from Go, Rust, and Haskell, released state-of-the-art image classification models – and answered thousands of questions on GitHub, StackOverflow, and the TensorFlow mailing list along the way.

At Google, TensorFlow supports everything from large-scale product features to exploratory research. We recently launched major improvements to Google Translate using TensorFlow (and Tensor Processing Units, which are special hardware accelerators for TensorFlow). Project Magenta is working on new reinforcement learning-based models that can produce melodies, and a visiting PhD student recently worked with the Google Brain team to build a TensorFlow model that can automatically interpolate between artistic styles. DeepMind has also decided to use TensorFlow to power all of their research – for example, they recently produced fascinating generative models of speech and music based on raw audio.

We’re especially excited to see how people all over the world are using TensorFlow. For example:

  • Australian marine biologists are using TensorFlow to find sea cows in tens of thousands of hi-res photos to better understand their populations, which are under threat of extinction. 
  • An enterprising Japanese cucumber farmer trained a model with TensorFlow to sort cucumbers by size, shape, and other characteristics.
  • Radiologists have adapted TensorFlow to identify signs of Parkinson’s disease in medical scans.
  • Data scientists in the Bay Area have rigged up TensorFlow and the Raspberry Pi to keep track of the Caltrain.

We’re committed to making sure TensorFlow scales all the way from research to production and from the tiniest Raspberry Pi all the way up to server farms filled with GPUs or TPUs. But TensorFlow is more than a single open-source project – we’re doing our best to foster an open-source ecosystem of related software and machine learning models around it:

  • The TensorFlow Serving project simplifies the process of serving TensorFlow models in production.
  • TensorFlow “Wide and Deep” models combine the strengths of traditional linear models and modern deep neural networks. 
  • For those who are interested in working with TensorFlow in the cloud, Google Cloud Platform recently launched Cloud Machine Learning, which offers TensorFlow as a managed service.

Furthermore, TensorFlow’s repository of models continues to grow with contributions from the community, with more than 3000 TensorFlow-related repositories are listed on GitHub alone! To participate in the TensorFlow community, you can follow our new Twitter account (@tensorflow), find us on GitHub, ask and answer questions on StackOverflow, and join the community discussion list.

Thanks very much to all of you who have already adopted TensorFlow in your cutting-edge products, your ambitious research, your fast-growing startups, and your school projects; special thanks to everyone who has contributed directly to the codebase. In collaboration with the global machine learning community, we look forward to making TensorFlow even better in the years to come!

By Zak Stone, Product Manager for TensorFlow