Merge pull request #1765 from austinshenk/patch-1

Update elm-upgrade link to master branch

Author: evancz

upgrade-docs/0.19.md

@@ -11,7 +11,7 @@ To make the process as smooth as possible, this document outlines all the things
 - [Stricter Record Update Syntax](#stricter-record-update-syntax)
 - [Removed User-Defined Operators](#removed-user-defined-operators)
 
-> **Note:** You can try out [`elm-upgrade`](https://github.com/avh4/elm-upgrade/tree/rc#elm-upgrade--) which automates some of the 0.18 to 0.19 changes. It is also in an alpha stage, and Aaron has said it makes sense to talk things through [here](https://github.com/avh4/elm-upgrade/issues).
+> **Note:** You can try out [`elm-upgrade`](https://github.com/avh4/elm-upgrade#elm-upgrade--) which automates some of the 0.18 to 0.19 changes. It is also in an alpha stage, and Aaron has said it makes sense to talk things through [here](https://github.com/avh4/elm-upgrade/issues).
 
 <br>
 
@@ -159,4 +159,4 @@ They are still able to define that function, but it will need a human readable n
 
 ## Notes:
 
-- `toString` &mdash; A relatively common bug was to show an `Int` in the UI, and then later that value changes to something else. `toString` would just show wrong information until someone noticed. The new `String.fromInt` and `String.fromFloat` ensure that cannot happen. Furthermore, more elaborate types almost certainly need localization or internationalization, which should be handled differently anyway.
+- `toString` &mdash; A relatively common bug was to show an `Int` in the UI, and then later that value changes to something else. `toString` would just show wrong information until someone noticed. The new `String.fromInt` and `String.fromFloat` ensure that cannot happen. Furthermore, more elaborate types almost certainly need localization or internationalization, which should be handled differently anyway.