Show new version + upgrade help text in CLI

[cpojer]

The CLI is a good place to notify people of new releases and give them more information about upgrades.

My proposal:

• Periodically check for new RN releases when invoking the RN CLI and surface that people can upgrade with react-native upgrade.
• When running react-native upgrade, show the breaking changes in red with a link to a blog post and the changelog:

React Native 0.60

Breaking Changes:
* Description of a breaking change and a link. 
* Description of a breaking change and a link.
* Description of a breaking change and a link.
For more information read:
* Blog post with link
* See the full changelog

I'm not entirely sure what the best way to implement is. I was thinking that release branches could have a file Upgrade.txt and the CLI could read that file straight from GitHub and display its contents.

What do you think?

[grabbou]

I'm not entirely sure what the best way to implement is. I was thinking that release branches could have a file Upgrade.txt and the CLI could read that file straight from GitHub and display its contents.

Since we need to check for a release anyway with a network request, we could read a section from the releases tab, e.g: https://github.com/facebook/react-native/releases/tag/v0.58.5

Additionally to what you've said, I'd leave an option to mute this banner on per-project for those who are intentionally using CLI with older versions.

[cpojer]

Parsing the info from the release and tagging the CLI output in a special block seems like a great idea to me.

[grabbou]

Sounds good. I'd love to pick this up after we cut 0.60-stable branch (around a week from now) and see what are the next steps. What do you think?

[cpojer]

Yeah!

[cpojer]

(You meant 0.59 stable I assume :) )

[grabbou]

I'll try to see if I can make it land before we make 0.59 stable. If not, then it will be a 0.60.0 feature. Will do my best!

[matei-radu]

May I interest you in some GitHub APIs? Try this in your browser:

https://api.github.com/repos/facebook/react-native/releases/latest

Docs: https://developer.github.com/v3/repos/releases/#get-the-latest-release

The response has all we need:

• tag_name to check if the release is newer
• draft and prerelease to filter out newer but undesired releases
• body which is the entire release markdown as a string that shouldn't be too hard to display.

What about API rate limits?

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.

Docs: https://developer.github.com/v3/#rate-limiting

I don't think this will be a problem, because:

• It's per IP address, so it should scale well.
• Displaying this information isn't vital for the CLI's functionality: we could attempt to check only weekly and cache the results.

What do you think? I'd be happy to give this a try 😄

[cpojer]

That sounds great. Do you wanna send a PR? :)

[matei-radu]

Sure, I'll come up with something during the week

[grabbou]

Awesome, thanks for taking up the work! If you need any help from the release format perspective, let me know! I think the style for now will be to just keep the "releases" tab small and link to a separate repository, so printing the whole "body" sounds like a plan.

(+1 for some fancy colours)

[matei-radu]

@grabbou initially I thought to take a similar approach to npm and use boxen to decorate the update message, so I ended up with:

For this particular case, I'm not using our custom logger to avoid printing the info labels to the left of the rows.

Of course, the post-upgrade message can be different and print the entire release body.

What do you think?

[cpojer]

I think this is a great start, feel free to send a pull request.

After that we can define a specific template that we'll follow for all releases so that we can print the header of the release section on GitHub right on the terminal, including the top breaking changes so they are shown right in people's faces.

[thymikee]

To be even more friendly, and help those upgrading more than 1 version up, we need to batch breaking changes from previous releases (this will also be necessary if e.g. we upgrade from 0.59.0 to 0.60.4 – with naive approach the breaking changes from 0.60.0 would be gone.)