This describes the technical, theoretical steps of a release. (For all the organizational steps and actual commands to execute, please refer to the Detailed Release Process Documentation below.)
master
of the project you want to releasemaster
directly):master
that should not be part of the release?1.2.3
after 1.3.0
has already been released) or a minor release after there was a new major release (1.7.0
after 2.0.0
has already been released)1.2.x
) on the last “good” commit (before the first one that should not be included in the release) or last released tag/commit and check it out (or check out the existing release branch for b))master
that should be included to the checked out release branchRELEASENOTES.md
and commit-dev
suffix in version and Release Notes (and commit)vote/x.y.z
dist/dev
-dev
back (and commit)dist/dev
to dist/release
x.y.z
release tagmaster
dist/dev
, unbump patch on release branch (and commit and push)This list also does not include steps that are only required for one type of component:
cordova.js
, propagate version number to other platform files (which those are depends on the platform), tag master
of cordova-js
with new platform version, make sure documentation is up to date or create PR that can be merged after release, Android only: Publish to BintrayREADME.md
is correctplatformsConfig.json
, all: update cross dependencies between libraries,The detailed documentation below does include these at the appropriate locations.
This generalized release process is supported and partly automated by our cordova-coho
CLI tool. As details of this process are different depending on what kind of package you want to release, we have individual detailed release process documentation that contains the actual commands to run: