v1.9.0-beta

This release introduces a few account management features. It is available now on NPM and can be installed by running npm i -g code-push-cli@latest.

New Features

1. CodePush accounts can now use both Microsoft and GitHub credentials to login We introduced a new code-push link command that allows you to link an additional identity provider to an existing CodePush account. So if you registered with MS and want to link GitHub, or vice-versa, you now can.
2. We introduced a new code-push whoami command that allows you to display the e-mail address of the account you are currently logged in to the CLI as, as well as the list of identity providers your account is currently linked to (see above)

v1.8.2-beta

This release simply fixes a bug with the release-cordova command on Windows.

v1.8.1-beta

This is a feature-packed release that introduces numerous highly requested enhancements. It is available now on NPM and can be installed by running npm i -g code-push-cli@latest.

New Features

1. Updates can now be "flighted" to only a percentage of your users The release command (and derivatives) includes a new parameter called --rollout that allows you to specify the percentage of users you want to be eligible to receive it. This way you can roll releases out slowly, watch your analytics and crash reporting data to see if everything looks good, and slowly roll it out to more users as desired. More details

   code-push release-react MyApp ios --rollout 25%

2. The metadata of existing releases can now be edited We introduced a new patch command that lets you edit the mandatory, description, disabled (see below) and rollout properties of an existing release within a specific deployment. This way, if you need to correct a typo in a description, make a release mandatory or optional, or increase the rollout percentage of a flighted release, you can. More details

   code-push patch MyApp Production --rollout 80%
   code-push patch MyApp Staging --label v5 -m false

3. Releases can now be disabled The release, release-react, release-cordova (see below), patch and promote (see below) commands all now include a new --disabled parameter, which allow you to indicate whether you want a released, edited or promoted update to be downloadable or not.

   // Upload a new release but don't make it immediately available for users
   code-push release-react MyApp ios --disabled
   
   ...
   // When you are ready to release, simply enable the already uploaded update
   code-push patch MyApp Production --disabled false

4. Update metadata can now be overridden when promoting a release The existing promote command works by creating a new release in the destination deployment, whose content and metadata are equivalent to that of the latest release in the source deployment. In order to support modifying the metadata of the new release, the promote command now includes parameters for --mandatory, --description, --disabled and --rollout. This is effectively a shortcut for doing the promote followed by patch, if you want to ensure that certain attributes are changed immediately as part of the promotion. This can be helpful, for example, if you're using the mandatory and/or description fields differently in Staging and Production. More details.

   code-push promote MyApp Staging Production -m false

5. Releasing updates to Cordova apps is now much simpler We introduced a new release-cordova command that handles the cordova prepare and code-push release automatically, and infers the app's version and update contents location. This is the Cordova-equivalent of the existing release-react command, and now ensures that developers using either platform have a simpler solution, while still being able to use the "vanilla" release command when more control/flexibility is needed More details

   Before:

   cordova prepare ios
   code-push release MyApp ./platforms/ios/www 1.0.0

   After:

   code-push release-cordova MyApp ios

Bug Fixes

1. The ZIP file that is created by the CLI when you run the release command is now appropriately deleted even if the release process is rejected (e.g. you attempted to upload an update that is identical to the latest release) or fails.
2. We resolved an install issue for users running older NPM versions

Breaking Changes

As mentioned in the release notes for the 1.7.0-beta release, we needed to make some breaking changes between the CLI and CodePush server in order to accommodate some performance improvements and feature enhancements. We ended up maintaining both the old and new management servers for two weeks, but as of the 1.8.1-beta release, the old management server is gone, and all users MUST upgrade to 1.7.0+ (we would encourage using 1.8.1-beta since it has a ton of new features!) to continue managing their account.

Once again, to be extremely clear, this will have no impact on end-users at all. It only impacts the CLI and your ability to release updates, not device's ability to receive updates.

If you are reading this, and have already upgraded to the latest CLI, then you don't need to do anything else. If you haven't upgraded to a 1.7.0-beta+ version of the CLI at this point, you will simply get an error message in the CLI asking you to upgrade, at which point, you just simply need to run npm i -g code-push-cli@latest and you're good to go.

v1.7.0-beta

This release introduces general CLI performance improvements across the board, as well as a handful of highly requested feature items. It is available now on NPM and can be installed by running npm i -g code-push-cli@latest.

New Features

1. We finally polished up and shipped the Node.js management SDK that underlies our CLI. This allows you to write automated build scripts more easily, without needing to shell out to the CLI. You can find out details for getting started here.
2. The release command now allows you to specify a semver range as the value of the targetBinaryVersion parameter, which allows you to target a single CodePush release at multiple binary versions (if desired). You can continue to release to specific versions (e.g. 1.4.5), but you now have the flexibility to perform complex release strategies based on the binary compatibility policies that suit your needs (e.g. >=1.2.3, 1.1.*). Refer to the CLI docs for more details on this new capability.
3. A new code-push deployment clear command has been introduced to the CLI, which allows you to keep an existing deployment and key (which may have already been configured within an app), but clear the release history. This can be helpful during debugging or POC scenarios, where you iterated on a lot of releases, and now want to clean things up without needing to create a new deployment with a new key.
4. We added two new optional parameters to the existing release-react command: --bundleName and --dev. The former lets you customize the name of the JS bundle which is generated (it defaults to main.jsbundle) if desired, and the --dev flag is simply a pass-through to the equivalent option in the react-native CLI.

Breaking Changes

To accommodate the performance improvements that we made to the server, we needed to make some breaking changes that will require users to be on 1.7.0+ of the CLI to continue managing their accounts. We will be maintaining the old/compatible server for the next two weeks, but after that, we will require users to upgrade. It only requires a single NPM command, so it shouldn't be too difficult :) To be extremely clear, this will have no impact on end-users at all. It only impacts the CLI and your ability to release updates, not device's ability to receive updates.

If you are reading this, and have already upgraded to the latest CLI, then you don't need to do anything else. However, we will be phasing out the old server in two weeks, and at that point, if you haven't upgraded to this release (or newer), you will get an error message asking you to upgrade.

v1.6.1-beta

The release introduces the release-react command, which simplifies release workflows for React Native apps.

New Features

1. A new release-react command is introduced which automates the process of preparing and releasing the update contents of React Native apps to CodePush. This means that developers no longer need to run the react-native bundle command to generate the update contents into a temporary folder before running the code-push release command - they simply run code-push release-react <AppName> <platform> and the CLI handles genering the update contents. In addition, release parameters such as the targetBinaryVersion will be inferred from the app metadata using information from the Info.plist or build.gradle files, depending on whether the specified platform is iOS or Android.

v1.6.0-beta

The release introduces the highly-requested app collaborator feature, which adds support for the following two scenarios:

1. Sharing a CodePush-created app with other developers, so that you can all release/promote/rollback updates to it (without needing to rely on a shared access key or user session file!).
2. Transferring the ownership of an app to another developer (in the event that you're not working on it anymore), while still maintaining all of its release history, deployments and collaborators.

This update is available now on NPM and can be installed by running npm i -g code-push-cli@latest. Refer to the App Collaborator section in the CLI docs for more information on how to start using it.

Bug Fixes

1. The Update metadata column, within the output of the code-push deployment ls command, now displays a message to indicate if it hasn't had any updates release to it yet ("No updates released"), as opposed to simply being blank.

v1.5.0-beta

This release introduces the new installation metrics feature to the CLI, which let's you identify the total number of installations that every update has received, as well as how many active installations it currently has (i.e. this is the version that an end-user would see when running your app). Note that this feature depends on the 1.5.0+ release of the Cordova plugin and the 1.6.0+ release of the React Native plugin, since those include the necessary telemetry. So if you want to begin viewing installation metrics, you'll need to upgrade your respective plugin and submit a new app store update (sorry!). This update is now available on NPM and can be installed immediately via npm i -g code-push-cli@latest.

New Features

1. The deployment ls and deployment history commands now display basic metrics for each CodePush release, which help you understand: how many total (and pending) installations each release has, how many of those installations are active, and whether or not any client-side rollbacks have occurred (i.e. because you released an update that crashed). Hopefully no one release an update via CodePush that is broken, but if you do, the plugin will make sure that your end-users are seamlessly rolled back, and the CLI will let you know about the failure so that you can respond accordingly! (e.g. by doing a server-side rollback to prevent other users from getting it).

Bug Fixes

1. The release command wasn't properly rejecting *.ipa and *.apk files, which made it possible for devs to mistakenly attempt to release a binary file, only to have it fail to install, since neither the Cordova or React Native plugin expects that.
2. We heard a lot of feedback about confusion around the "package" and "appStoreVersion" parameters of the release command. Because of this, we have renamed them to "updateContentsPath" and "targetBinaryVersion", respectively. These parameters are positional so their names wouldn't break existing behavior, but we hope that the description and examples displayed within the CLI are now a little more intuitive.

Breaking Changes

1. The Deployment Key column within the deployment ls command is now hidden by default, since it took up a lot of space, and wasn't regularly needed. To display this value, simply pass the new -k (or --displayKeys) flag when calling deployment ls.

v1.4.1-beta

This release fixes a regression that caused the --description parameter to erroneously become required when executing the code-push release command.

v1.4.0-beta

This is largely a bug fix release that also introduces a feature enhancement to the existing rollback command. You can update your global code-push-cli installation from NPM immediately to take advantage of these improvements.

New Features

1. The rollback command accepts a new optional flag called --targetRelease (or -r) that allows you to roll back to an arbitrary version within the deployment, as opposed to simply the previous release. This change was made after lots of customer feedback, and we're happy to unblock this scenario!

Bug fixes

1. The description parameter of the release command now correctly parses whitespace characters (e.g. \n, \t), so you can add newlines/etc. to your release descriptions.
2. The Package Hash field has been removed from the Package Metadata column that is displayed when running code-push deployment ls. This field required the table to be unnecessarily wide in order to render correctly, and it also wasn't adding a lot of value to users anyways.

v1.3.0-beta

This is a feature release which introduces a few new capabilities and no breaking changes. You can update your global code-push-cli installation from NPM immediately to take advantage of these improvements.

New Features

1. A new code-push rollback command lets you easily "undo" a release that was unintended or has issues. This was a top user request, so we're happy to get it in! See the docs for more info on how to use it.

2. A progress bar is now displayed when releasing an update, so that you have a better idea of how long it will take. This was also a frequent request from users.

   

3. We now display an update notification if you are running an out-of-date version of the CLI. To keep it unobtrusive, it is only displayed at most once a day, and only shows up when running code-push. Running any other command (e.g. code-push app ls) won't display the update notification.