Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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!

Lorenzo 'kelset' Sciandra

April 17, 2020
Tweet

More Decks by Lorenzo 'kelset' Sciandra

Other Decks in Programming

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

    View full-size slide

  2. Hello!
    My name is Lorenzo Sciandra
    • Software Engineer @ Formidable UK

    • React Native core maintainer

    • ProvidedAsIs organiser
    #RemoteSummit @kelset @formidableLabs
    2
    @kelset

    View full-size slide

  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!)

    View full-size slide

  4. Releases: why?
    #RemoteSummit @kelset @formidableLabs
    4

    View full-size slide

  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

    View full-size slide

  6. Releases: how?
    #RemoteSummit @kelset @formidableLabs
    6

    View full-size slide

  7. How we release stuff
    kelset.dev
    #RemoteSummit @kelset @formidableLabs
    7
    Simple example
    commit GitHub Netlify
    push hook “CD”

    View full-size slide

  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

    View full-size slide

  9. How we release stuff
    #RemoteSummit @kelset @formidableLabs
    9
    Hard example
    react native
    ./scripts/bump-oss-version.js 0.XX.0
    CI

    View full-size slide

  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

    View full-size slide

  11. What is that complexity?
    #RemoteSummit @kelset @formidableLabs
    11

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  15. “How do we solve this problem?”
    #RemoteSummit @kelset @formidableLabs
    15
    We solve what we can, we work around what we can't

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  19. Is 1.0 the final solution?
    #RemoteSummit @kelset @formidableLabs
    19
    Should you wait for it to use it in prod?

    View full-size slide

  20. NO
    #RemoteSummit @kelset @formidableLabs
    20

    View full-size slide

  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

    View full-size slide

  22. Are we doomed??
    #RemoteSummit @kelset @formidableLabs
    22
    Does it mean we should never use React Native in production?

    View full-size slide

  23. HECK, NO
    #RemoteSummit @kelset @formidableLabs
    23

    View full-size slide

  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!

    View full-size slide

  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

    View full-size slide

  26. Yes, the 1.0 is a lie
    #RemoteSummit @kelset @formidableLabs
    26
    Use React Native and have fun!

    View full-size slide

  27. THANK YOU!
    Lorenzo Sciandra
    @kelset
    [email protected]
    Stick around for:

    • Q&A

    • Speaker room

    • Advice lounge for 1.5 hrs

    https://calendly.com/kelset/remotesummit?month=2020-04
    27
    @formidablelabs
    #RemoteSummit

    View full-size slide