Releases: microsoft/code-push
v1.10.0-beta
New Features
-
You can now release updates to your React Native apps on Windows 10 devices In order to align with the new Windows support for React Native, the
release-react
command now supports specifyingwindows
as the platform, which will generate the appropriate app update, infer your app's version and release it to CodePush! We look forward to working with the community as the support for Windows continues to evolve. View the CLI docs for more details.$ code-push release-react MyApp windows
-
The
release-cordova
command now includes an additional flag called--build
(or-b
), which specifies that you want to run acordova build
instead of simplycordova prepare
when generating your app update. This can be helpful if your app relies on before or after Cordova build hooks. View the CLI docs for more details.# Release an update to CodePush that will # ensure your Cordova build hooks are executed $ code-push release-cordova MyApp ios -b
v1.9.1-beta
New Features
-
The
patch
andpromote
commands include a new optional parameter called--targetBinaryVersion
(or-t
), which allows you to edit the respective attribute for an existing CodePush release. This change makes it so that all metadata associated with a release is editable via a patch or promote operation, and allows you to correct a mistake made when performing a release, increase or decrease the binary version compatibility of a release and/or use different versioning schemes between deployments.# Add a "max binary version" to an existing release # by scoping its eligibility to users running >= 1.0.5 code-push patch MyApp Staging -t "1.0.0 - 1.0.5" # Promote the release to production and make it # available to all versions using that deployment code-push promote MyApp Staging Production -t "*"
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
- 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. - 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
-
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 detailscode-push release-react MyApp ios --rollout 25%
-
The metadata of existing releases can now be edited We introduced a new
patch
command that lets you edit themandatory
,description
,disabled
(see below) androllout
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 detailscode-push patch MyApp Production --rollout 80% code-push patch MyApp Staging --label v5 -m false
-
Releases can now be disabled The
release
,release-react
,release-cordova
(see below),patch
andpromote
(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
-
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, thepromote
command now includes parameters for--mandatory
,--description
,--disabled
and--rollout
. This is effectively a shortcut for doing thepromote
followed bypatch
, 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 themandatory
and/ordescription
fields differently inStaging
andProduction
. More details.code-push promote MyApp Staging Production -m false
-
Releasing updates to Cordova apps is now much simpler We introduced a new
release-cordova
command that handles thecordova prepare
andcode-push release
automatically, and infers the app's version and update contents location. This is the Cordova-equivalent of the existingrelease-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 detailsBefore:
cordova prepare ios code-push release MyApp ./platforms/ios/www 1.0.0
After:
code-push release-cordova MyApp ios
Bug Fixes
- 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. - 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
- 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.
- The
release
command now allows you to specify a semver range as the value of thetargetBinaryVersion
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. - 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. - 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 tomain.jsbundle
) if desired, and the--dev
flag is simply a pass-through to the equivalent option in thereact-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
- 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 thereact-native bundle
command to generate the update contents into a temporary folder before running thecode-push release
command - they simply runcode-push release-react <AppName> <platform>
and the CLI handles genering the update contents. In addition, release parameters such as thetargetBinaryVersion
will be inferred from the app metadata using information from theInfo.plist
orbuild.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:
- 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!).
- 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
- The
Update metadata
column, within the output of thecode-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
- The
deployment ls
anddeployment 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
- 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.
- 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
- The
Deployment Key
column within thedeployment 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 callingdeployment 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.