-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
7 additions
and
8 deletions.
There are no files selected for viewing
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -40,6 +40,7 @@ aren't as concerned with syncing updates, then follow these steps: | |
| ## Developing | ||
|
|
||
|
|
||
| ### Branches | ||
|
|
||
| #### `master` branch - The latest dev (beta) release | ||
|
|
@@ -50,19 +51,17 @@ This is typically where the latest development happens. Code that is in the mast | |
|
|
||
| Each package is tagged with beta version numbers, and published to npm such as `@ohif/[email protected]` | ||
|
|
||
| ### `release` branch - The latest stable release | ||
|
|
||
| This branch represents the latest stable version of the project that is considered ready for production. The code in this branch should be fully tested and vetted for release. Once the code in the master branch reaches a state where it's stable and ready to be released to users, | ||
| we do a comprehensive code review and QA testing. Once the code is approved, | ||
| we merge it into the release branch and tag a new release. | ||
| ### `release/*` branches - The latest stable releases | ||
| Once the `master` branch code reaches a stable, release-ready state, we conduct a comprehensive code review and QA testing. Upon approval, we create a new release branch from `master`. These branches represent the latest stable version considered ready for production. | ||
|
|
||
| Each package is tagged with version numbers, and published to npm such as `@ohif/ui@3.5.0` | ||
| For example, `release/3.5` is the branch for version 3.5.0, and `release/3.6` is for version 3.6.0. After each release, we wait a few days to ensure no critical bugs. If any are found, we fix them in the release branch and create a new release with a minor version bump, e.g., 3.5.1 in the `release/3.5` branch. | ||
|
|
||
| Note: `master` is always ahead of `release` branch. We publish both docker builds for beta and stable releases. | ||
| Each package is tagged with version numbers and published to npm, such as `@ohif/[email protected]`. Note that `master` is always ahead of the `release` branch. We publish docker builds for both beta and stable releases. | ||
|
|
||
| Here is a schematic representation of our development workflow: | ||
|
|
||
|  | ||
|  | ||
|
|
||
|
|
||
|
|
||
| ### Requirements | ||
|
|
||