[draft] Path to launching Expo Dev Tools about expo-cli HOT 8 CLOSED

I think steps 3-4 can happen quickly, I deliberately didn't add dates so we can move fast if possible. I think "move fast but carefully" might be a good compromise to "just make default overnight" ?

from expo-cli.

Thanks for putting this together @terribleben, it looks really good.

1. Gather team feedback

I agree with @tcdavis that we should resolve top issues from the team before moving to step 2. Otherwise the feedback from partners will focus too much on the issues/bugs and it will be harder to get in depth feedback.

3. Announce more widely, don't set as default

Perhaps the banner in XDE shouldn’t say “deprecated” until the first stable version of devtools is out? This way we don’t force XDE users to switch to “beta software” from a stable tool. At first it could say something like “try new Expo Developer Tools” and after the cutoff date “XDE is deprecated, please switch to Expo Developer Tools”.

Switch the default

I think this step should include switching the React Native docs over to Expo CLI from CRNA.

from expo-cli.

I think @ccheever mentioned something about just making it the default already. But I'm also open to this plan.

Thanks for putting this together @terribleben, I can't wait for @freiksenet and @fson to weigh in :)

from expo-cli.

Understood! Thanks for clarifying.

from expo-cli.

Relative to new users, our existing user base a) will have a harder time adjusting to a new tool and b) is more valuable to us (both per user and in total) so I'd sequence things a little differently

1a Respond to top issues from internal feedback

Since the beta users will tend to only tell us their top n things, we'll get a lot better feedback if we resolve the things we already know about first

2 Gather Partner Feedback

What Ben said + maybe more of a focus on deeper feedback from fewer people. Cycling back to some of the folks from the original interviews might be nice.

3 Switch the default

Update expo.io to steer new users to the new tool, but don't try to popularize it to our existing users or prompt them to switch. If there's something important we didn't catch in 1 & 2 it will be easy to tell (if not figure out what exactly it is) and fall back to the current content with minimal harm done. If everything is rosy move right ahead to 4

4 Announce to existing users and organically convert them to the new devtool

Figure out a specific migration path for how we plan to get everybody on the new workflow (from old exp, from XDE, from old CRNA)

• Get existing users to try the new tooling
• Get enough of them to use it for their main development environment because it's just better

5 Sunset XDE

Set the date when XDE will no longer be supported. Notify existing users. Disable new downloads of XDE

from expo-cli.

No part of the original timeline includes a provision or mechanism for forcing existing users to switch. So I'm not sure how your "4 Switch existing users" is distinct from the existing proposal.

from expo-cli.

Updated to hopefully be a bit clearer. Yes didn't mean point 4 to be a significant departure from your proposal; the bigger difference is how we order new vs existing users

I don't think we're planning to go out and intentionally disable the existing tools, but once we stop building it and label it unsupported, we are going to be forcing people to switch.

from expo-cli.

Closing this issue as Expo CLI has already been launched!

from expo-cli.