From 62c2c17a4fbf89b01e60635412e41b414e4fa1d2 Mon Sep 17 00:00:00 2001 From: austinshenk Date: Mon, 27 Aug 2018 12:12:40 -0400 Subject: [PATCH] Update elm-upgrade link to master branch --- upgrade-docs/0.19.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/upgrade-docs/0.19.md b/upgrade-docs/0.19.md index cc42e7a78..aba61372c 100644 --- a/upgrade-docs/0.19.md +++ b/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).
@@ -159,4 +159,4 @@ They are still able to define that function, but it will need a human readable n ## Notes: -- `toString` — 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. \ No newline at end of file +- `toString` — 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.