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.

v1.2.3-beta

This is a bug-fix release which adds better error logging when releasing an update and improves the output of various commands. You can update your global code-push-cli installation from NPM immediately to take advantage of these improvements.

Bug fixes (App management)

1. The ID column was removed from the output of the app ls command. This value was completely internal and didn't make any sense being displayed to users.
2. A new Deployments column has been added to the app ls command which displays a comma-separated list of deployments that each app has.
3. The Package column has been removed from the list of deployments that are auto-created when adding a new app via the app add command. This column was always blank since a newly created deployment obviously couldn't have had any releases made to it yet.

Bug fixes (Releasing updates)

1. The release command now reports an error when the appStoreVersion parameter isn't semver compliant. This has always been a requirement on the server, but the CLI didn't enforce it.
2. The release command now rejects specifying a zip file via the package parameter. This has always been a requirement on the server, but the CLI didn't enforce it.
3. The deployment history command now sorts the releases in ascending order so that the most recent update is at the bottom. This makes it easier to use since most terminals will automatically scroll you to the bottom of a command's output.