Description: 
We have an enterprise customer requesting to give customers the ability allow ChromeOS version pinning to latest major version (69.x, 70.x, etc.) whenever the said version hits stable.  

Use case: 
Enterprise customers deploy managed ChromeOS devices across across the world. To ensure that these devices operate as expected at all times, the team conducts an extensive continuous testing of all software updates by leveraging the Dev, Beta and Stable release channels.

Let’s assume that a device version (say 69) has been approved and pushed to all the devices, but 70 isn’t because a bug has been introduced. The team is currently unable to proactively pin the highest version of Chrome to 69 in the cPanel until Version 70 hits the stable channel. Not enabling customers to immediately pin a version of the OS introduces the risk that, by the time the team is notified that the new, now unauthorized, version hits the stable channel, some devices may download and update to that version, causing these devices to be rendered unoperational.

Motivation:
The customer is a large company with Chrome devices in thousands of franchise stores. Franchises are focused on delivering the business value and purchases supplies and equipment from Corporate. The expectation is that these devices, for security and staffing purposes, are managed centrally by Corporate.

It isn’t scalable to have IT personnel roaming across the world to manage Chrome devices worldwide. In fact, every component delivered to the stores is managed by Corporate IT.

Implementing this feature will ensure business continuity as these Chrome devices are set to become part of the critical systems at each and every store. These devices are business critical systems designed to support Digital Signage, Check-in, Payment, Delivery Dispatch, Customer Order Pickup, and the the manufacturing queue and employee training. Introducing a risk by being unable to immediately pin to a ChromeOS version is just too big of a risk for the organization.

As they have experienced already (versions 64 through 68), some bugs can be introduced, which prevent them from leveraging the kiosks properly. Once a device updates to an invalid version, the solution stops working all together and requires a re-imaging of the device. The customer cannot ship USB sticks to restore the devices (not scaleable, the devices are impossible to manage, security risk, lack of training on the topic at the store, onerous), the expectation is for the store to ship back all bricked devices back and receive replacements, which incurs costs and delays.

Existing workarounds:
At the moment, the only workaround is to ensure that all devices in the fleet (growing every day) is up to date on the latest major ChromeOS version. Once this condition is satisfied, the customer would disable Auto Update all together from the cPanel to prevent these devices from auto-updating to a non-approved device version. This prevents them from receiving all minor updates on these devices, which can be security related. Furthermore, this change requires multiple changes in production and pre-production systems, which requires the approval of the Change Control Team.