Point releases concentrate risk. And in the cloud, that's not smart. The point release mind set no longer applies when you operate in the cloud. In the on-premises world, we bundle literally thousands of code changes into a single point release. The aggregation of value from each of the many code changes compensate for the effort an on-premises customer needs to expend in order to update servers, clients, directories, etc in their global environment. In the cloud, there is little to no effort by the customer to upgrade to the new release. So there is no particular reason to concentrate all the code changes in a point release. Instead, we can spread the risk by deploying in much smaller increments, one component at a time. Architectural separation of the solution components is pivotal to building an environment in which we can update one component without requiring a simultaneous update of another. Since our LotusLive (IBM SmartCloud) system in large part hosts code that was originally developed for on-premises products, where architectural separation of components was a lesser concern, we are now making a series of changes to further separate components. In that process, we are also reducing code complexity; a great benefit to go along with the risk reduction. This all leads to more frequent, and smaller, releases. We are now seeing our collaboration services deploy so-called Tune-Ups roughly monthly. They can contain both fixes and new function. Whenever new function is included, there is a need to enable the subscribers with information about the new functionality and how to use it. That's a good reason to group the changes by component, refreshing one component at a time, rather than a number of scattered updates across all the components. The stream of updates still has to be consumable to the subscribers, who will often want to update their help desks for each change. A random stream of changes would be confusing to both help desks and end users. Groups of changes around a particular component or theme are much more consumable. This 'grouping' strategy requires a reasonably rapid release cycle, so no single component has too long a cycle to bring updates to the production environment.