Nodemailer release process can be described in the following steps
- A milestone issue is created in GitHub that describes the goals for the planned version. This issue also records progress towards the milestone
- Development happens in a branch dedicated to this version, eg branch=v2.1
- Progress is initially tagged as VERSION-TAG.COUNT where VERSION is the target version and COUNT is the incrementing build number. TAG is initially beta
- Once a beta version is tagged it is published to npm with the beta tag (
npm publish --tag beta). You can always install the latest development version of Nodemailer from npm with
npm install nodemailer@beta
- Once all functionality is completed then dependency version numbers are locked and TAG is changed from beta to rc. After this point there should not be any feature changes
- rc versions get also published to npm beta channel. There is no separate channels for beta and rc TAG
- If first rc version is published then stable release date is planned to be 7 days from the release of the first rc
- If for whatever reason new features are added to a following rc version, then stable release date is moved to 7 days after the updated rc release.
- Once 7 days are passed from the last changing rc version, the current rc is republished as stable. This means merging the development branch into master, changing version number in package.json (from VERSION-TAG.COUNT to VERSION) and publishing it to npm without the beta-tag
- Meanwhile I edit the docs in Nodemailer homepage. If the release bumps major version then a completely new set of documentation is added. If it bumps minor version, then existing documentation for the same major version is updated.