0.62.x Discussion

[grabbou]

Opening this issue thread as a placeholder that we will be starting to work on 0.62.0-rc.0 now that 0.61.0 is shipping.

I will post an update here once we have a better understanding of the timeline.

[grabbou]

Now that 0.61.2 has finally shipped fixing a long-standing elevation regression on Android, I am going to look into 0.62.

[ursnj]

What all major features planning for 0.62 ???

very much eager to know, that i loved the Fast refresh in 0.61 :)

Kudo's to the team.

[sebqq]

@ursNj Brand new react dev tools ❤️

[ursnj]

improving Flatlist performance is really needed, as many times i saw that application is lagging due to flat list. even i have tried all the optimization techniques for Flatlist, still issue is there. its is very much required.

[grabbou]

It is not specified yet. I will let you know as soon as the branch cut works and we are ready to push out a new release.

Right now, tests are failing because of two issues and I am waiting for an update.

[anchengjian]

Remove create-react-class and it's related writing to avoid duplication of fbjs dependency.

[grabbou]

The Android CI has been fixed. There's work to resolve iOS issues. I will update you as soon as I have more information.

[grabbou]

I have taken a look at the CI today and tried to break down failures to specific commits. I have managed to progress by reverting some of them and fixing a few of the issues in place. Unfortunately, there are few commits that can't be easily reverted. In both cases, I have outlined them below.

Here's a summary of reverted commits:

• https://github.com/facebook/react-native/commit/561cbbe2e9025f6f6ff3fb98267adb6502be99d8 - removes Flipper integration for iOS projects. Not sure why it breaks, but the failing test suite is here if you want to help with digging.

Here's a summary of commits that break the CI but can't be reverted:

• https://github.com/facebook/react-native/commit/a397d330a4cf7e08095faa0e751e38d5106ed5c7 - this commit changes gray shades in RNTester, causing our snapshot tests to fail. A fix should be to safely re-generate snapshots and make sure it's just the colors we are overwriting to ensure no bugs are slipping through. It's coupled with other parts of RN, so reverting isn't safe and easy. PR submitted: https://github.com/facebook/react-native/pull/27059

• https://github.com/facebook/react-native/commit/0d54b1c23f9d8943cfa5380eb9a16cd4dd2ae34e - some changes to this and other modules break CocoaPods "use_frameworks!" tests. Can't be easily reverted. See my comment below for details.

[grabbou]

Unfortunately, the tests are still failing because of the TurboModules commits that are causing "Undefined symbols for architecture x86_64" error.

You can find a failure for RCTSettings module here. Looks like it only happens when used with "use_frameworks" (CocoaPods setup).

I will try to work on resolving this issue and apply https://github.com/facebook/react-native/commit/0d54b1c23f9d8943cfa5380eb9a16cd4dd2ae34e again. I believe there's one fix needed for all modules that were made TurboModules-compatible to make compiler pass.

Meanwhile, maybe @fkgozali and @jtreanor - you have an idea how this could be approached? I remember you were involved in working towards support for "use_frameworks!" in first place.

[grabbou]

The tests are green. I would like to thank everyone for the help with getting the commits and fixes in place! Especially @RSNara!

We are now evaluating whether to release with October, 13th commits or to re-cut from master (will require few more days to fix tests).

[sebqq]

Re-cut 🥳😄

[kelset]

I agree - if CI is green on master I'd probably just re-cut it since it could at least reduce the difference between the released version and master from a month-ish to a few days / a week

[mikehardy]

"if CI is green on master"... - but, nope: master is solid red https://github.com/facebook/react-native/commits/master

Just for grins I kept paging back looking for a green check. July 18 is the last time master passed CI? https://github.com/facebook/react-native/commits/master?after=56c7ae729a03f44558763e3d86def3a269513bbb+1049

I'm not recommending a course of action but if I'm reading history right that's the facts

Actually, I would recommend getting CI to pass on master ;-) as a "come on everyone let's take a break for a minute agree this is a priority and do this" type deal but I'm not sure I'd hold 0.62 for it

[kelset]

oh wow - yeah sounds like there should be an effort in getting master back to green that 👀

But then, if instead the current state of 0.62 is a green CI, I would proceed with the current one and not rebase.

[grabbou]

There's been a few fixes and tweaks here on 0.62-stable to make it pass and all of them have been backported to master since then. Unfortunately, that means we are dealing with a different failure reason now.

I'll check how time-consuming that might be and will report back.

[grabbou]

CC: @TheSavior and @cpojer, I'd love to get your thoughts on wheter to release as is or sync with master.

There's been some additional context in the recent comments too!

[cpojer]

I think the consideration should be about how many more releases we want to have this year and when. The two options I see are:

1. Stabilize 0.62 now and release it in November, cut a new stable at the end of the year and target a January release for 0.63
2. Re-cut 0.62 in mid-November and make a stable release in mid-December, then make 0.63 happen in February.

I don't want to influence your decision on this too much but given that you already put a lot of work into stabilizing 0.62, it's probably a good idea to release it (please write a brief blog post!) and then we'll cut the next release after the holidays.

[grabbou]

Thank you @cpojer for giving your input into the discussion. As you said, I think it's a good idea to release 0.62 right now, with the primary reason being the timing and avoiding unnecessary pressure throughout December.

I believe that releasing a stable version at the end of the year (say December) and cutting the next release candidate early next year (January) is the best way going forward and will help us wrap things up before getting offline for the New Year's Eve.

That said, I am going to proceed with it right now and will write a comment here once the results are online.

[grabbou]

There is a little issue with Android build system (similar to https://github.com/react-native-community/jsc-android-buildscripts/issues/80). Previously, it was only happening inside RNTester. Now, it also happens while building a new app.

Going to consult this with Facebook team and find a reasonable solution/workaround today before proceeding further.

Note: This shouldn't delay the release any longer, it's just a tiny little tweak I want to do before releasing to save everyone from doing the fix themselves.

[thymikee]

CLI bump: https://github.com/facebook/react-native/commit/e523302fbe055e6745e38b72a17e121341c431c1

[grabbou]

Turns out the issue is brought up by recent Flipper update. Investigating with the team on the next steps.

[dnlowman]

Is there any update to the status of this?

[Fausto95]

is RN0.62 coming with Flipper support?

[grabbou]

@dnlowman yes - it took a while because I was awaiting an investigation from the Flipper team. There's a known workaround that is going to ship for now. We will see what to do with that next week.

@Fausto95 yes.

[grabbou]

I have already pushed a fix, going to test it and publish 0.62.0-rc.0.

It's been a while since I cut the branch, so I will take an additional time today & tomorrow to look at it once again and make sure everything works.

[ursnj]

app bundles crash issue in play store will fix with this release ???https://github.com/facebook/react-native/issues/25927

[grabbou]

Unfortunately, the Android app build is broken on my machine (despite the CI passing, where we don't test "a default app", but ReactAndroird as a whole).

I need to take a closer look at the failures.

In the meantime, let's focus on shipping additional tweaks to 0.61 - there's going to be more work on 0.62 needed to get it out. I will do my best to get it out as soon as possible, however, please keep in mind there is a lot of developers working on this behind the scenes and I am just delivering the updates.

That said, wish you a great weekend and hopefully, there's going to be more updates early next week.

[sebqq]

Hello @grabbou! Isn't it worth to consider re-cut and delay (release) once again?

[ltcaosj]

Can we include this PR to RN0.62? Allow touches on clipped children when clipChildren==false PR #26374 This will make a consistent UI behaviour between iOS and Android.

[DKolev]

Hello.

I was wondering if in any the upcoming releases, there is a fix related to the problematic cookie based authentication problem in Android. While we were on 0.59.9, we used the workaround with ReadableNativeArray.setUseNativeAccessor(true); ReadableNativeMap.setUseNativeAccessor(true);

But we had to upgrade to the latest 0.61.4 and now our login for Android is completely broken.

[pinstripe-potatohead]

Hello.

I was wondering if in any the upcoming releases, there is a fix related to the problematic cookie based authentication problem in Android. While we were on 0.59.9, we used the workaround with ReadableNativeArray.setUseNativeAccessor(true); ReadableNativeMap.setUseNativeAccessor(true);

But we had to upgrade to the latest 0.61.4 and now our login for Android is completely broken.

I believe this was fixed in v0.61.5

[DKolev]

Hello. I was wondering if in any the upcoming releases, there is a fix related to the problematic cookie based authentication problem in Android. While we were on 0.59.9, we used the workaround with ReadableNativeArray.setUseNativeAccessor(true); ReadableNativeMap.setUseNativeAccessor(true); But we had to upgrade to the latest 0.61.4 and now our login for Android is completely broken.

I believe this was fixed in v0.61.5

10x a lot. Indeed it was fixed. I guess 0.61.5 was released a couple of hours after my question here.

[akshetpandey]

I second holding off 0.62 release and recutting in January. The holiday season would mean low exposure for the rc builds and no one available to make fixes if required.

[kelset]

As pointed out by @cpojer a while ago, a lot of work went into stabilising 0.62 "as-is".

It looks like master branch CI is still red (like, 6 jobs out of 13 are failing 👀), and since that has been the case for a while (as pointed out by @mikehardy), I would probably instead go a different route.

@grabbou Android has always been a bit flaky during the local E2E testing - what if we just push out the 0.62-rc0 out as is and see what happens? I'm pretty sure that the rc0 part of the release will keep most people "safe" from trying it, and we can get a larger pool of people to test it and detect what is currently failing on yours.

[grabbou]

@kelset unfortunately, the Android doesn't work right now. The tests are surprisingly passing, so it's not a matter of flaky tests this time.

What fails is the react-native inited application, which is only tested manually and not on the CI.

For reference, here's an excerpt from the stack traces:

2019-11-22 08:53:12.233 4932-4983/? E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
    Process: com.rntestproject, PID: 4932
    java.lang.UnsatisfiedLinkError: No implementation found for long com.facebook.yoga.YogaNative.jni_YGConfigNew() (tried Java_com_facebook_yoga_YogaNative_jni_1YGConfigNew and Java_com_facebook_yoga_YogaNative_jni_1YGConfigNew__)
        at com.facebook.yoga.YogaNative.jni_YGConfigNew(Native Method)
        at com.facebook.yoga.YogaConfigJNIBase.<init>(YogaConfigJNIBase.java:23)
        at com.facebook.yoga.YogaConfigJNIFinalizer.<init>(YogaConfigJNIFinalizer.java:11)
       ...

2019-11-22 09:05:58.246 7133-7133/com.rntestproject E/SoLoader: Error when loading lib: dlopen failed: library "libjsc.so" not found lib hash: a0869b08725ad34d2f9c99602c9b316e search path is /data/app/com.rntestproject-tZ-YSeUocEWoe7yuj7iLBg==/lib/x86
2019-11-22 09:05:58.252 7133-7133/com.rntestproject E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found

I am currently trying out a re-cut to see if the issues still persist there. It is easier to push with a broken CI (when some functionality might be broken) rather than with a not working app 😅

[kelset]

Oh, I see :( I misunderstood what you meant with Android not working 😓

Ok let us know how that goes 🤞

[cimitan]

Hi, did anyone try with git bisect to figure out the commit to blame for this regression?

[KingAmo]

hi, any update on 0.62?

[grabbou]

I haven't tried that @cimitan and you're more than welcome to help us debug this! In the meantime, I have re-cut 0.62 branch off master under a different name and I am estimating the effort needed to unbreak the tests there.

The current 0.62-stable branch is blocked by the aforementioned Android issues which Flipper team was looking into fixing. No updates here.

[cimitan]

Quite busy this week, maybe I'll get the chance to test one of those nights. I'll report back if I start, shouldn't take long with bisection

[grabbou]

Facebook team removed all 0.62-stable branches after our request and there's now a new branch, straight off the master which seems to be working.

We're doing tests right now and hoping to do the release pretty soon.

[robertying]

It seems 0.62 is close to release, but I’m wondering if there’s any chance to include this fix for iPad split views?

https://github.com/facebook/react-native/commit/7a72c35a20a18c19bf6ab883cb2c53a85bd4c5c0

Thank you!

[hramos]

@robertying I've cherry-picked https://github.com/facebook/react-native/commit/7a72c35a20a18c19bf6ab883cb2c53a85bd4c5c0 onto 0.62-stable.

[lukebars]

Any updates on estimated release date? :shipit:

[kelset]

At the moment, we are testing the new branch - 0.62.0 will happen in 2020. We may (or may not) manage to get an rc out before end of the year but no promises, sorry.

[gaodeng]

The release process of 0.62 has been going through almost three months 😱,Can we study Flutter's build release channels and learn from them . https://github.com/flutter/flutter/wiki/Flutter-build-release-channels

[kelset]

@gaodeng while I understand that you may find frustrating that it's been a slow process, I can assure you that we have been trying our best to make it happen in a reliable fashion (no one wants to release a broken version) - we have been documenting our efforts in this issue precisely so that we'd be transparent on our attempts.

Also, I find a bit unfair for you to compare the two libraries as they have a really different workloads and approaches - as the releases for RN are mostly managed by members of the community, who are not paid to work on this.

It's already quite stressful to work on this process - without the additional negativity that comments like yours provide 😓 So please be more understanding of our position, there are humans on the other side of the screen.

[Off2Race]

@kelset — I hope you can ignore the negativity. There are many, many of us out here that greatly value the work that you and all the members of the community contribute. Keep up the great work. We appreciate you!

[gaodeng]

I just told the truth, I didn’t expect it would hurt you

[cimitan]

Issues and mistakes happen, it's human. Having worked for several years in the past in the free software community, I can assure those things happen, it's no big deal.

We need to learn and iterate, how can we improve the process for 0.63? That's going to be a separate discussion, not to be held here.

Thanks to the team for your work here, we appreciate the effort despite the busy holiday period!