39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
|
# How to develop LoopBack 3.0
|
||
|
|
|
||
|
|
## Keeping track of major and breaking changes
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
## Branch setup
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
## Publishing pre-release versions
|
||
|
|
|
||
|
|
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
|
||
|
|
|
||
|
|
1. changed the version string to `"3.0.0-alpha.1"`
|
||
|
|
2. 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.
|