The 1.0 is a Lie

Whenever there's a conversation about working on React Native, versioning and release cycle usually arise as one of the pain points.
But why is that the case? How complicated is it to create a new release of React Native? Surely it looks similar to the release process you are using... or not!
During this talk I'll walk you through the many steps and complexities involved in publishing a new version or React Native, and I'll challenge one fundamental idea – that 1.0 is the solution to all problems.
I hope you're ready, it's going to be wild!

Transcript

1. The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie the 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie The 1.0 Is a Lie
2. Hello! My name is Lorenzo Sciandra • Software Engineer @ Formidable UK • React Native core maintainer • ProvidedAsIs organiser #RemoteSummit @kelset @formidableLabs 2 @kelset
3. Tales from the releaser • Been a developer since ~0.30 • Been a releaser since 0.57: #RemoteSummit @kelset @formidableLabs 3 What about you? Warning: this talk is from my POV. Which is not the “official” one. (write down your questions for Q&A after this!)
4. Releases: why? #RemoteSummit @kelset @formidableLabs 4
5. Why we release stuff Allow other people to use our code (kind of obvious, isn’t it?) 
 Introduce a level of static-ness (which is why I don’t like npm’s dynamic dependencies) Reproducibility (which is particularly important in the mobile world) #RemoteSummit @kelset @formidableLabs 5
6. Releases: how? #RemoteSummit @kelset @formidableLabs 6
7. How we release stuff kelset.dev #RemoteSummit @kelset @formidableLabs 7 Simple example commit GitHub Netlify push hook “CD”
8. commit commit commit commit commit commits How we release stuff #RemoteSummit @kelset @formidableLabs 8 Medium example actual app I worked on (maybe) Generate tag CI tool branch push ✅ / store download
9. How we release stuff #RemoteSummit @kelset @formidableLabs 9 Hard example react native ./scripts/bump-oss-version.js 0.XX.0 CI
10. How we release stuff 1. create the stable branch ex. ‘0.XX-stable’ 2. create a dedicated issue on the ‘releases’ repo 3. clone & checkout locally, and clean the setup 4. test locally via ./scripts/test-manual-e2e.sh until ✅ 5. publish the stable branch as an RC via ./scripts/bump-oss-version.js 0.XX.0-rc0 6. create a GitHub release for RC 7. generate changelog PR yarn generate --base v0.XX-1.X --compare v0.XX.0-rc0 --repo ../react-native --token [GITHUB TOKEN] 8. generate new version of documentation for website 9. start working on the blogpost PR 10.create the rn-diff for the upgrade helper 11.iterate on the release candidate: 1. cherry-pick needed and requested commits that apply cleanly or with minimal effort 2. if necessary, do minor fixes directly to the stable branch, (MUST back-port to master asap) 3. test locally via ./scripts/test-manual-e2e.sh until ✅ 4. publish new RC ./scripts/bump-oss-version.js 0.XX.0-rcY 5. update changelog PR 6. repeat from step until consensus is reached 12.test locally via ./scripts/test-manual-e2e.sh until ✅ 13.publish the stable branch as a stable version via ./scripts/bump-oss-version.js 0.XX.0 14.publish_npm_package workflow on CI, keep an eye on it 15.Merge changelog PR 16.Merge blogpost PR 17.create a GitHub release for stable 18.Bump defaultVersionShown in the website’s config 19.check that it works via npx react-native init TestRelease --version 0.XX.0 #RemoteSummit @kelset @formidableLabs 10 (the real) React Native Preparation phase RC phase .0 release phase For the actual list, please see: https://github.com/react-native-community/releases/tree/master/docs
11. What is that complexity? #RemoteSummit @kelset @formidableLabs 11
12. The RN complexities Generic #RemoteSummit @kelset @formidableLabs 12 • We care about our community • The codebases moves fast • What we depend on also keeps moving We need to produce changelogs, blogposts, diffs, documentation, etc.
 We need to test as much as we can (both manual and CI) Around 400 commits every month https://github.com/facebook/react-native/graphs/commit-activity Ex. the reactjs requires a sync 
 (ex. https://github.com/facebook/react-native/commit/862c71908c8bdbbddefed16ad03fa85c26eedfd1)
 Ex. Android & iOS have a new version release each year
13. The RN complexities React Native specific #RemoteSummit @kelset @formidableLabs 13 1. FB uses it differently 
 → no react-native init, in monorepo 2. FB mirroring process 
 → internal commits land directly on master branch 3. FB can always have the last word
 → requirements may change with the code moving fast, doing patch releases can be a problem
 (ex. cherry picking a particular commit may lead to git conflicts) • The release process goes through branches • FB is the owner of React Native, community manages releases
14. Let’s review those steps #RemoteSummit @kelset @formidableLabs 14 1. create the stable branch ex. ‘0.XX-stable’ 2. create a dedicated issue on the ‘releases’ repo 3. clone & checkout locally, and clean the setup 4. test locally via ./scripts/test-manual-e2e.sh until ✅ 5. publish the stable branch as an RC via ./scripts/bump-oss-version.js 0.XX.0-rc0 6. create a GitHub release for RC 7. generate changelog PR yarn generate --base v0.XX-1.X --compare v0.XX.0-rc0 --repo ../react-native --token [GITHUB TOKEN] 8. generate new version of documentation for website 9. start working on the blogpost PR 10. create the rn-diff for the upgrade helper 11. iterate on the release candidate: 1. cherry-pick needed and requested commits that apply cleanly or with minimal effort 2. if necessary, do minor fixes directly to the stable branch, (MUST back-port to master asap) 3. test locally via ./scripts/test-manual-e2e.sh until ✅ 4. publish new RC ./scripts/bump-oss-version.js 0.XX.0-rcY 5. update changelog PR 6. repeat from step until consensus is reached 12. test locally via ./scripts/test-manual-e2e.sh until ✅ 13. publish the stable branch as a stable version via ./scripts/bump-oss-version.js 0.XX.0 14. publish_npm_package workflow on CI, keep an eye on it 15. Merge changelog PR 16. Merge blogpost PR 17. create a GitHub release for stable 18. bump defaultVersionShown in the website’s config 19. check that it works via npx react-native init TestRelease --version 0.XX.0 Preparation phase RC phase .0 release phase For the actual list, please see: https://github.com/react-native-community/releases/tree/master/docs Community material Extra testing Base
15. “How do we solve this problem?” #RemoteSummit @kelset @formidableLabs 15 We solve what we can, we work around what we can't
16. Solving & Workarounding Solving #RemoteSummit @kelset @formidableLabs 16 • Introduced the RC phase • Increase the number of people involved in the process • Increase communication with FB Since 0.60 To increase the surface area of testing From one (either me or @grabbou) plus one for docs (@charperni or @hramos)
 To at least 4 to 6 - among which @alloy from Microsoft and folks from the RN team Thanks to Eli and Eloy and other team members from FB Via the RN Contributors Discord and the releases issue
17. Solving & Workarounding Workarounding #RemoteSummit @kelset @formidableLabs 17 → we incrementally iterate on the process and improve it • It’s unlikely that a successful upgrade can be a 1 line script • We can’t fully automate the process → we’ve created the upgrade helper and started the Upgrade Support repo
18. Let’s sum up the situation #RemoteSummit @kelset @formidableLabs 18 • Releasing React Native is complicated • The codebases moves fast • All the parties involved are actively working on improving this For both generic and specific reasons Both the community members and Facebook’s team and Microsoft devs
19. Is 1.0 the final solution? #RemoteSummit @kelset @formidableLabs 19 Should you wait for it to use it in prod?
20. NO #RemoteSummit @kelset @formidableLabs 20
21. Let me explain #RemoteSummit @kelset @formidableLabs 21 • 1.0 is a promise of finalised product • 1.0 does not mean the product is not usable • 1.0 promises long term support Take the example of GMail, which stayed in beta for 5 years after being opened to the public:
 “the label is just a way for Google to signal users that they’re still tweaking the e-mail service and adding new features” There is simply not enough people working on react native right now to commit to this https://semver.org/#doesnt-this-discourage-rapid-development-and-fast-iteration It’s all semantics https://slate.com/news-and-politics/2009/07/why-google-kept-gmail-in-beta-for-so-many-years.html
22. Are we doomed?? #RemoteSummit @kelset @formidableLabs 22 Does it mean we should never use React Native in production?
23. HECK, NO #RemoteSummit @kelset @formidableLabs 23
24. Hek, no React Native is already usable #RemoteSummit @kelset @formidableLabs 24 We are addressing its rollout in the least “breaking” way possible • There is a long term plan: the new architecture • It's been used successfully all around the world for years Microsoft - Shopify - Amazon - Activision Blizzard - Sony - Coinbase And hundreds and hundreds more!
25. At the end of the day #RemoteSummit @kelset @formidableLabs 25 • The release process is complicated, but for good reasons • React Native is still moving, as we constantly improve too • A potential 1.0.0 numeration is still far away
26. Yes, the 1.0 is a lie #RemoteSummit @kelset @formidableLabs 26 Use React Native and have fun!
27. THANK YOU! Lorenzo Sciandra @kelset notkelset@kelset.dev Stick around for: • Q&A • Speaker room • Advice lounge for 1.5 hrs
 https://calendly.com/kelset/remotesummit?month=2020-04 27 @formidablelabs #RemoteSummit