We will need a detailed release notes for 3.0. To make our life easier, we
should build them incrementally in a file called 3.0-RELEASE-NOTES.md.
Each pull request containing a major change must include an update
of this file describing the change for a user upgrading from 2.x to 3.0.
Most patches should be landed on the master branch, the new 3.0 release will be eventually released from master too.
It is up to the discretion of reviewers to decide which changes to back-port from master to 2.x. Initially, we should probably land all bug fixes and most backwards-compatible enhancements. This rule should be revisited once 3.0.0 was released.
To make it easy for LB developers to test out the upcoming 3.0 version, we should regularly publish pre-release versions to npmjs. However, extra care must be taken to ensure "npm install" keeps downloading the current 2.x series.
When 2.x branch was created, we have changed package.json on the master branch and
- changed the version string to
"3.0.0-alpha.1" - added the following bit:
"publishConfig": { "tag": "next" }
Whenever making a new pre-release version, increment the latest number:
3.0.0-alpha.2, 3.0.0-alpha.3, etc. Once get closer to the release date,
we can release 3.0.0-beta.1, possibly also 3.0.0-rc.1.
The benefit of this version scheme is that module consumers can use carrot
operator to get automatic updates: "^3.0.0-alpha.1" matches all versions
from the previous paragraph.