You should always deploy a new version of an App Engine app when you upload a new version of your MapReduce application code or a new major or minor version of the MapReduce library. You should be careful if you are running a MapReduce job and updating at the same the time.

When you change your source code, or update the MapReduce library, please consider these compatibility issues.

Updating your app

MapReduce jobs run to completion using the app version they had when they started. A running job is not affected when you deploy a new version of your app.

For example, if app version v2 is performing a MapReduce job, you can safely deploy a newer app version v3. The running version v2 job will not be affected, even if version v3 includes a different MapReduce library. Once the running job ends, you can delete version v2. Doing this makes deployments safer because you don't need to worry whether or not the new version of your code is compatible with the older version.

It is not good practice to deploy a change to the same version of an app while a MapReduce job is running. Your app may then have multiple instances, some running the old version, and some running the new version simultaneously. If there are incompatible changes in the uploaded code (or any of the libraries on which it depends, including the MapReduce library), the job may not complete successfully. One exception to this rule: You can safely deploy a patch level change to the MapReduce library over an existing app version.

Updating the MapReduce library

Unlike the services that are part of the App Engine runtime, the MapReduce library is an ordinary library that's deployed with your application. This means that the runtime code used by a MapReduce job will not change unless you redeploy your application with a new version of the library.

The version number for the MapReduce library is composed of three levels: major . minor . patch . A previously deployed version of your app may be able to run with a newer version of the MapReduce library, but there is no guarantee. For best results, follow these rules:

• Library changes made at the patch level (for example 1.0.0 to 1.0.1) are backwards-compatible and can be deployed right away.
• Library changes made at the minor level (for example 1.0.0 to 1.1.0) may have some impact on your application. For instance, an API parameter or internal data structure in the library might change.
• When the major version changes (1.0.0 to 2.0.0), you should inspect your code for compatibility.
  

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our Site Policies .