The 1.0 is a Lie

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!

C7171fc9d27bc81913733c6703093a61?s=128

Lorenzo Sciandra

April 17, 2020
Tweet

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