Update release process and master becomes the stable branch

.teamcity/OpenSourceProjects_Storybook/buildTypes/OpenSourceProjects_Storybook_Docs.kt

@@ -12,7 +12,7 @@ object OpenSourceProjects_Storybook_Docs : BuildType({
     artifactRules = "docs/public => docs.zip"
 
     params {
-        param("Deploy branch", "release/4.0")
+        param("Deploy branch", "master")
     }
 
     vcs {

README.md

@@ -26,8 +26,8 @@ It allows you to browse a component library, view the different states of each c
 
 README for:
 
-- [![Alpha](https://img.shields.io/npm/v/@storybook/core/alpha.svg)](https://github.com/storybooks/storybook)
-- [![Latest](https://img.shields.io/npm/v/@storybook/core/latest.svg)](https://github.com/storybooks/storybook/tree/release/4.0)
+- [![Alpha](https://img.shields.io/npm/v/@storybook/core/alpha.svg)](https://github.com/storybooks/storybook/tree/next)
+- [![Latest](https://img.shields.io/npm/v/@storybook/core/latest.svg)](https://github.com/storybooks/storybook/tree/master)
 
 Storybook runs outside of your app. This allows you to develop UI components in isolation, which can improve component reuse, testability, and development speed. You can build quickly without having to worry about application-specific dependencies.
 

RELEASES.md

@@ -2,11 +2,19 @@
 
 A Storybook release process based on [Semver](http://semver.org/). In short:
 
-1.  Merge bugfix PRs directly into master automatically release (~daily)
+1.  Merge all PRs into `next`, which is the default branch. Cherry-pick bugfix PRs into `master`, which is the stable release.
 
-2.  Merge feature and breaking PRs into a release branch (e.g. `release/3.2`) and release features in groups along with a marketing push after a preview period (~monthly)
+2.  Every week: release patch releases off `master` to the NPM tag `latest`, and alpha releases off `next` to the NPM tag `next` (as e.g. `4.1.0-alpha.0`).
 
-3.  Consensus on critical infrastructure/bugs that are needed before we can do a minor release, so that we pay down our tech debt as we go.
+3.  Every month or two, merge `next` into `master` and release a minor/major version according to `semver`. We set minor release dates as soon as we have feature clarity and manage to those dates:
+    - Date should be a Monday so if we slip we don't get pushed into the weekend
+    - T-3wk:
+      - Draft announcement and socialize
+      - Announce dates in #maintenance so people can react
+    - T-1wk:
+      - If you want your feature in the release, it should already be released on next by this time
+      - Create release branch and only cherrypick bugfixes
+      - Set up launch plan
 
 ## Motivation
 
@@ -38,8 +46,8 @@ releases. We'll try our best to restrict breaking changes to MAJOR releases.
 ## PATCH releases
 
 Every bugfix should go out as soon as we've verified the fix, and based on the
-current rate of contribution, we should be issuing PATCH releases multiple times per week.
-Soon we'll automate the process so that a release will go out every time a PR is
+current rate of contribution, we should be issuing PATCH releases weekly.
+Eventually we'll automate the process so that a release will go out every time a PR is
 merged into `master`, and we've already laid most of the groundwork for this.
 
 ## MINOR releases
@@ -51,11 +59,7 @@ hierarchy for stories) deserves more attention:
 2.  They often have architectural implications for the entire Storybook ecosystem, so should be discussed thoroughly before release. Doing `alpha` releases allow us to test in the community without necessarily achieving agreement.
 3.  They often deserve proper marketing treatment (blog posts, release announcement, podcast, etc.)
 
-Therefore we merge these into a release branch of the form `release/MAJOR.MINOR`
-and we create preview releases and get them tested by the community before
-merging those branches into `master`.
-
-> NOTE: it is possible to edit the `base` branch in a PR, so we can expect users to issue PRs to `master`, but as maintainers as we see feature releases we should set them to merge into the appropriate release branch.
+Therefore we release `alpha` versions continuously on the NPM `next` tag to allow people to test out features as soon as they are ready.
 
 In general we should release 2-3 headline features per minor release for
 marketing purposes. Each headline feature should get its own blog post on the
@@ -64,11 +68,7 @@ post.
 
 ## MAJOR releases
 
-We should avoid major releases, and should try to do these at most 1-2x per
-year. Ideally each breaking change would have been agreed upon by the
-maintainers and validated in backwards-compatible feature releases. At some
-point once a change has been thoroughly vetted, we deprecate the old way and
-give some time for people to upgrade to the new way. Finally MAJOR releases
+We should avoid major releases, but won't hold ourselves back on this. Making storybook better is the prime directive, and if we have to make breaking changes to do it, we will. That said, MAJOR releases
 should have killer features that reward users for upgrading, and should not be
 used to scratch our own architectural itches -- unless those itches are really
 killing development in some meaningful way.
@@ -114,4 +114,4 @@ in a patch release.
 #### How does my PR get merged?
 
 - For PATCH PR's, any maintainer can review, test, approve, and merge it.
-- For MINOR/MAJOR PR's, once a maintainer reviews, tests, and approves it, s/he should clear it with the other maintainers before merging it into the release branch.
+- Once a release date has been set and we cut off merging, we'll create a temporary branch to hold that release so that it doesn't block merging to `next`.

addons/notes/README.md

@@ -8,7 +8,7 @@ Storybook Addon Notes allows you to write notes (text or HTML) for your stories
 
 ### Getting Started
 
-**NOTE: Documentation on master branch is for alpha version, stable release is on [release/4.0](https://github.com/storybooks/storybook/tree/release/4.0/addons/)**
+**NOTE: Documentation on master branch is for alpha version, stable release is on [master](https://github.com/storybooks/storybook/tree/master/addons/)**
 
 ```sh
 yarn add -D @storybook/addon-notes

addons/ondevice-notes/README.md

@@ -8,7 +8,7 @@ Storybook Addon On Device Notes allows you to write notes (text or markdown) for
 
 ### Getting Started
 
-**NOTE: Documentation on master branch is for alpha version, stable release is on [release/4.0](https://github.com/storybooks/storybook/tree/release/4.0/addons/)**
+**NOTE: Documentation on master branch is for alpha version, stable release is on [master](https://github.com/storybooks/storybook/tree/master/addons/)**
 
 ```sh
 yarn add -D @storybook/addon-ondevice-notes

docs/src/pages/addons/addon-gallery/index.md

@@ -11,46 +11,46 @@ This is a list of available addons for Storybook.
 
 With a11y you can test compliance of your stories with web accessibility standards.
 
-### [Actions](https://github.com/storybooks/storybook/tree/release/4.0/addons/actions)
+### [Actions](https://github.com/storybooks/storybook/tree/master/addons/actions)
 
 With actions, you can inspect events related to your components. This is pretty neat when you are manually testing your components.
 
 Also, you can think of this as a way to document events in your components.
 
-### [Links](https://github.com/storybooks/storybook/tree/release/4.0/addons/links)
+### [Links](https://github.com/storybooks/storybook/tree/master/addons/links)
 
 With links you can link stories together. With that, you can build demos and prototypes directly from your UI components.
 
-### [Knobs](https://github.com/storybooks/storybook/tree/release/4.0/addons/knobs)
+### [Knobs](https://github.com/storybooks/storybook/tree/master/addons/knobs)
 
 Knobs allow you to edit React props dynamically using the Storybook UI.
 You can also use Knobs as dynamic variables inside your stories.
 
-### [Notes](https://github.com/storybooks/storybook/tree/release/4.0/addons/notes)
+### [Notes](https://github.com/storybooks/storybook/tree/master/addons/notes)
 
 With this addon, you can write notes for each story in your component. This is pretty useful when you are working with a team.
 
-### [Info](https://github.com/storybooks/storybook/tree/release/4.0/addons/info)
+### [Info](https://github.com/storybooks/storybook/tree/master/addons/info)
 
 If you are using Storybook as a style guide, then this addon will help you to build a nice-looking style guide with docs, automatic sample source code with a PropType explorer.
 
-### [Options](https://github.com/storybooks/storybook/tree/release/4.0/addons/options)
+### [Options](https://github.com/storybooks/storybook/tree/master/addons/options)
 
 The Storybook webapp UI can be customised with this addon. It can be used to change the header, show/hide various UI elements and to enable full-screen mode by default.
 
-### [Storyshots](https://github.com/storybooks/storybook/tree/release/4.0/addons/storyshots)
+### [Storyshots](https://github.com/storybooks/storybook/tree/master/addons/storyshots)
 
 Storyshots is a way to automatically jest-snapshot all your stories. [More info here](/testing/structural-testing/).
 
 ### [Console](https://github.com/storybooks/storybook-addon-console)
 
 Redirects console output (logs, errors, warnings) into Action Logger Panel. `withConsole` decorator notifies from what stories logs are coming.
 
-### [Backgrounds](https://github.com/storybooks/storybook/tree/release/4.0/addons/background)
+### [Backgrounds](https://github.com/storybooks/storybook/tree/master/addons/background)
 
 With this addon, you can switch between background colors and background images for your preview components. It is really helpful for styleguides.
 
-### [Viewport](https://github.com/storybooks/storybook/tree/release/4.0/addons/viewport)
+### [Viewport](https://github.com/storybooks/storybook/tree/master/addons/viewport)
 
 Viewport allows your stories to be displayed in different sizes and layouts in [Storybook](https://storybook.js.org). This helps build responsive components inside of Storybook.
 

lerna.json

@@ -1,7 +1,7 @@
 {
   "command": {
     "publish": {
-      "allowBranch": "release/4.0"
+      "allowBranch": "master"
     }
   },
   "npmClient": "yarn",