s/mithril/mithril@next/g, add v1 docs link [skip ci] (#2368)

This should help point users to the correct version if they plan to
install the release candidate, and it should help users find the
existing docs for v1.

README.md

@@ -36,7 +36,10 @@ Mithril supports IE11, Firefox ESR, and the last two versions of Firefox, Edge,
 
 ### npm
 ```bash
+# For the most recent stable version
 $ npm install mithril --save
+# For the most recent unstable version
+$ npm install mithril@next --save
 ```
 
 The ["Getting started" guide](https://mithril.js.org/#getting-started) is a good place to start learning how to use mithril.

docs/index.md

@@ -46,6 +46,8 @@ If you are an experienced developer and want to know how Mithril compares to oth
 
 Mithril supports IE11, Firefox ESR, and the last two versions of Firefox, Edge, Safari, and Chrome. No polyfills required.
 
+*Looking for the v1 docs? [Click here](archive/v1.1.6).*
+
 ---
 
 ### Getting started

docs/installation.md

@@ -18,7 +18,7 @@ If you're new to Javascript or just want a very simple setup to get your feet we
 ### NPM
 
 ```bash
-$ npm install mithril --save
+$ npm install mithril@next --save
 ```
 
 ---
@@ -32,7 +32,7 @@ $ npm init --yes
 
 2. install required tools
 ```bash
-$ npm install mithril --save
+$ npm install mithril@next --save
 $ npm install webpack webpack-cli --save-dev
 ```
 
@@ -83,7 +83,7 @@ npm init --yes
 Then, to install Mithril, run:
 
 ```bash
-npm install mithril --save
+npm install mithril@next --save
 ```
 
 This will create a folder called `node_modules`, and a `mithril` folder inside of it. It will also add an entry under `dependencies` in the `package.json` file
@@ -206,7 +206,7 @@ Live reload is a feature where code changes automatically trigger the page to re
 
 ```bash
 # 1) install
-npm install mithril --save
+npm install mithril@next --save
 npm install budo -g
 
 # 2) add this line into the scripts section in package.json

docs/nav-guides.md

@@ -26,3 +26,4 @@
 - Misc
 	- [Framework comparison](framework-comparison.md)
 	- [Change log/Migration](change-log.md)
+	- [v1 Documentation](archive/v1.1.6)

docs/releasing.md

@@ -19,7 +19,8 @@ $ git pull --rebase mithriljs next
 
 2. Determine patch level of the change
 3. Update information in `docs/change-log.md` to match reality of the new version being prepared for release
-4. Commit changes to `next`
+4. Replace all existing references to `mithril@next` to `mithril` if moving from a release candidate to stable.
+5. Commit changes to `next`
 
 ```
 $ git add .
@@ -34,20 +35,20 @@ $ git push mithriljs next
 
 ### Merge from `next` to `master`
 
-5. Switch to `master` and make sure it's up to date
+6. Switch to `master` and make sure it's up to date
 
 ```bash
 $ git checkout master
 $ git pull --rebase mithriljs master
 ```
 
-6. merge `next` on top of it
+7. merge `next` on top of it
 
 ```bash
 $ git merge next
 ```
 
-7. Clean & update npm dependencies and ensure the tests are passing.
+8. Clean & update npm dependencies and ensure the tests are passing.
 
 ```bash
 $ npm prune
@@ -57,34 +58,34 @@ $ npm test
 
 ### Publish the release
 
-8. `npm run release <major|minor|patch|semver>`, see the docs for [`npm version`](https://docs.npmjs.com/cli/version)
-9. The changes will be automatically pushed to your fork
-10. Push the changes to `MithrilJS/mithril.js`
+9. `npm run release <major|minor|patch|semver>`, see the docs for [`npm version`](https://docs.npmjs.com/cli/version)
+10. The changes will be automatically pushed to your fork
+11. Push the changes to `MithrilJS/mithril.js`
 
 ```bash
 $ git push mithriljs master
 ```
 
-11. Travis will push the new release to npm & create a GitHub release
+12. Travis will push the new release to npm & create a GitHub release
 
 ### Merge `master` back into `next`
 
 This helps to ensure that the `version` field of `package.json` doesn't get out of date.
 
-12. Switch to `next` and make sure it's up to date
+13. Switch to `next` and make sure it's up to date
 
 ```bash
 $ git checkout next
 $ git pull --rebase mithriljs next
 ```
 
-13. Merge `master` back onto `next`
+14. Merge `master` back onto `next`
 
 ```bash
 $ git merge master
 ```
 
-14. Push the changes to your fork & `MithrilJS/mithril.js`
+15. Push the changes to your fork & `MithrilJS/mithril.js`
 
 ```bash
 $ git push
@@ -93,7 +94,7 @@ $ git push mithriljs next
 
 ### Update the GitHub release
 
-15. The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the `docs/change-log.md` entry for the build.
+16. The GitHub Release will require a manual description & title to be added. I suggest coming up with a fun title & then copying the `docs/change-log.md` entry for the build.
 
 ## Updating mithril.js.org
 
@@ -117,6 +118,8 @@ $ git push mithriljs
 
 After the Travis build completes the updated docs should appear on https://mithril.js.org in a few minutes.
 
+**Note:** When updating the stable version with a release candidate out, ***make sure to update the index + navigation to point to the new stable version!!!***
+
 ## Releasing a new ospec version
 
 1. Ensure your local branch is up to date

docs/stream.md

@@ -46,10 +46,10 @@ var Stream = require("mithril/stream")
 You can also download the module directly if your environment does not support a bundling toolchain:
 
 ```markup
-<script src="https://unpkg.com/mithril-stream"></script>
+<script src="https://unpkg.com/mithril@next/stream"></script>
 ```
 
-When loaded directly with a `<script>` tag (rather than required), the stream library will be exposed as `window.m.stream`. If `window.m` is already defined (e.g. because you also use the main Mithril script), it will attach itself to the existing object. Otherwise it creates a new `window.m`. If you want to use streams in conjunction with Mithril as raw script tags, you should include Mithril in your page before `mithril-stream`, because `mithril` will otherwise overwrite the `window.m` object defined by `mithril-stream`. This is not a concern when the libraries are consumed as CommonJS modules (using `require(...)`).
+When loaded directly with a `<script>` tag (rather than required), the stream library will be exposed as `window.m.stream`. If `window.m` is already defined (e.g. because you also use the main Mithril script), it will attach itself to the existing object. Otherwise it creates a new `window.m`. If you want to use streams in conjunction with Mithril as raw script tags, you should include Mithril in your page before `mithril/stream`, because `mithril` will otherwise overwrite the `window.m` object defined by `mithril-stream`. This is not a concern when the libraries are consumed as CommonJS modules (using `require(...)`).
 
 ---