| 1 | # Publishing on distribution channels
|
| 2 |
|
| 3 | This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedbacks before distributing the release to all users.
|
| 4 |
|
| 5 | This example uses the **semantic-release** default configuration:
|
| 6 | - [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
|
| 7 | - [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
|
| 8 |
|
| 9 | ## Initial release
|
| 10 |
|
| 11 | We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit` to `master`. When pushing that commit, **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
|
| 12 |
|
| 13 | The Git history of the repository is:
|
| 14 |
|
| 15 | ```
|
| 16 | * feat: initial commit # => v1.0.0 on @latest
|
| 17 | ```
|
| 18 |
|
| 19 | ## Releasing a bug fix
|
| 20 |
|
| 21 | We can now continue to commit changes and release updates to our users. For example we can commit a bug fix with the message `fix: a fix` to `master`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@latest`.
|
| 22 |
|
| 23 | The Git history of the repository is now:
|
| 24 |
|
| 25 | ```
|
| 26 | * feat: initial commit # => v1.0.0 on @latest
|
| 27 | * fix: a fix # => v1.0.1 on @latest
|
| 28 | ```
|
| 29 |
|
| 30 | ## Releasing a feature on next
|
| 31 |
|
| 32 | We now want to develop an important feature, which is a breaking change. Considering the scope of this feature we want to make it available, at first, only to our most dedicated users in order to get feedback. Once we get that feedback we can make improvements and ultimately make the new feature available to all users.
|
| 33 |
|
| 34 | To implement that workflow we can create the branch `next` and commit our feature to this branch. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@next`. That means only the users installing our module with `npm install example-module@next` will receive the version `2.0.0`. Other users installing with `npm install example-module` will still receive the version `1.0.1`.
|
| 35 |
|
| 36 | The Git history of the repository is now:
|
| 37 |
|
| 38 | ```
|
| 39 | * feat: initial commit # => v1.0.0 on @latest
|
| 40 | * fix: a fix # => v1.0.1 on @latest
|
| 41 | | \
|
| 42 | | * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
|
| 43 | ```
|
| 44 |
|
| 45 | ## Releasing a bug fix on next
|
| 46 |
|
| 47 | One of our users starts to use the new `2.0.0` release and reports a bug. We develop a bug fix and commit it to the `next` branch with the message `fix: fix something on the big feature`. When pushing that commit, **semantic-release** will release the version `2.0.1` on the dist-tag `@next`.
|
| 48 |
|
| 49 | The Git history of the repository is now:
|
| 50 |
|
| 51 | ```
|
| 52 | * feat: initial commit # => v1.0.0 on @latest
|
| 53 | * fix: a fix # => v1.0.1 on @latest
|
| 54 | | \
|
| 55 | | * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
|
| 56 | | * fix: fix something on the big feature # => v2.0.1 on @next
|
| 57 | ```
|
| 58 |
|
| 59 | ## Releasing a feature on latest
|
| 60 |
|
| 61 | We now want to develop a smaller, non-breaking feature. Its scope is small enough that we don't need to have a phase of feedback and we can release it to all users right away.
|
| 62 |
|
| 63 | If we were to commit that feature on `next` only a subset of users would get it, and we would need to wait for the end of our feedback period in order to make both the big and the small feature available to all users.
|
| 64 |
|
| 65 | Instead, we develop that small feature commit it to `master` with the message `feat: a small feature`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@latest` so all users can benefit from it right away.
|
| 66 |
|
| 67 | The Git history of the repository is now:
|
| 68 |
|
| 69 | ```
|
| 70 | * feat: initial commit # => v1.0.0 on @latest
|
| 71 | * fix: a fix # => v1.0.1 on @latest
|
| 72 | | \
|
| 73 | | * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
|
| 74 | | * fix: fix something on the big feature # => v2.0.1 on @next
|
| 75 | * | feat: a small feature # => v1.1.0 on @latest
|
| 76 | ```
|
| 77 |
|
| 78 | ## Porting a feature to next
|
| 79 |
|
| 80 | Most of our users now have access to the small feature, but we still need to make it available to our users using the `@next` dist-tag. To do so we need to merge our changes made on `master` (the commit `feat: a small feature`) into `next`. As `master` and `next` branches have diverged, this merge might require to resolve conflicts.
|
| 81 |
|
| 82 | Once the conflicts are resolved and the merge commit is pushed to `next`, **semantic-release** will release the version `2.1.0` on the dist-tag `@next` which contains both our small and big feature.
|
| 83 |
|
| 84 | The Git history of the repository is now:
|
| 85 |
|
| 86 | ```
|
| 87 | * feat: initial commit # => v1.0.0 on @latest
|
| 88 | * fix: a fix # => v1.0.1 on @latest
|
| 89 | | \
|
| 90 | | * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
|
| 91 | | * fix: fix something on the big feature # => v2.0.1 on @next
|
| 92 | * | feat: a small feature # => v1.1.0 on @latest
|
| 93 | | * Merge branch master into next # => v2.1.0 on @next
|
| 94 | ```
|
| 95 |
|
| 96 | ## Adding a version to latest
|
| 97 |
|
| 98 | After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`. There should be no conflict as `next` is strictly ahead of `master`.
|
| 99 |
|
| 100 | Once the merge commit is pushed to `next`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
|
| 101 |
|
| 102 | The Git history of the repository is now:
|
| 103 |
|
| 104 | ```
|
| 105 | * feat: initial commit # => v1.0.0 on @latest
|
| 106 | * fix: a fix # => v1.0.1 on @latest
|
| 107 | | \
|
| 108 | | * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
|
| 109 | | * fix: fix something on the big feature # => v2.0.1 on @next
|
| 110 | * | feat: a small feature # => v1.1.0 on @latest
|
| 111 | | * Merge branch master into next # => v2.1.0 on @next
|
| 112 | | /|
|
| 113 | * | Merge branch next into master # => v2.1.0 on @latest
|
| 114 | ```
|
| 115 |
|
| 116 | We can now continue to push new fixes and features on `master`, or a new breaking change on `next` as we did before.
|