The 1.0 is a Lie

Welcome, everyone. I'm so glad to be here and talking with you all. And today, I'm going to talk to you about something that is really near and dear to my heart, and to probably most of you React Native developers.

So let's jump right into it. I'm Lorenzo. You may know me as Kalset. I'm a software engineer at Formidable for the U.K. office in London, where I live. I'm a React Native Core maintainer, which is maybe why you may know about me, and also an organizer for Provided As Is, which is a meetup here in London for open source maintainers, which I jokingly usually call group therapy for maintainers.

You see, today I want to talk about releases, but I want to make sure that we start with the right foot. So to give you a bit of context, I've been a developer in React Native, using React Native, for the last three years almost. So I've been around since version 30, more or less. And I've been a releaser since version 57. That one you see over there, in particular, is my first-ever release. This is to say that I've been around quite a while, but please, just make sure to remember that this talk is from my experience, my point of view. So don't take anything I say as official.

Also, I want to know about you. I know we have a chat going on. I'm going to read all your answers and your comments while doing the presentation. But please let me know which version you've been using since how long have you been around for React Native. It's really interesting, usually, to know how far back we can go. Sometimes people are even from version 20. And also, remember that if you have any questions for me, we have a Q&A after this, and we have a speakers' room, and there's also an advice lounge. So there's plenty of time to ask me anything that comes to your mind while seeing this presentation.

So let's dive into releases. And the first bit that I want to talk about is why do we do releases? It sounds quite simple, right? We want to provide somehow our code to other people so that they can use it, right? It's not just that. Technically, when you expose your code on GitHub, for example, the packages.json NPM allows you to technically point to any given repository without the need of a strict release in the NPM registry. But we do releases. We do versioning because we want to introduce a level of staticness. We want to say, okay, this is a version.

This is a version of the code. This is a package that I've decided is good enough for it to be given out as a sort of a unit. It's that. Also, this is one of the reasons why the dynamic dependencies, the use of the cara for some dependencies, I don't really like that. I prefer strict staticness. Why I like that? Because it allows reproducibility. In particular in the mobile world, I really want to minimize the possibility for me to not be able to get to the point in time to that snapshot precise for that code. For example, if I need to test the previous version of the app I released, I need to make sure that the code and every single piece of code I'm using, or at the most part, as much as I can control, is precisely the same so that I can work on it.

That said, how do we release? To sort of like tackle this question, I've decided to go for some examples. So, let's start with a simple one. Calcet.dev is my website, and it's awful. Please, please, please don't go. Don't look at it. It's ugly. You're going to hate me for going there. So, don't hate me. Just trust that it exists. I push it up on GitHub, then there's a Git hook that gets triggered, and that leads Netlify to do its magic, and then the code is ready. It's out there. It's released, and it rides into the sunset.

Now, of course, this is really simple. Let's try to go for a better one, for one that comes from my past, in my experience. This is potentially an app I worked on, I don't want to say too much about it, but basically we had a bunch of commits. Whenever we wanted to do a new release, we do a branch from master. We generate a tag on this new branch. We push this up, and we have a CI tool that runs a series of triggers that are getting triggered by this tag. And then once it's all green, and it's all done, we have an app ready to be bundled, ready to be sent to the stores, where the users can download it and ride into the sunset.

And now React Native, this is the hard example. So we run a script, and it runs... It just goes into the sunset. Yeah, okay, of course. That's not it, right? Yeah, of course, it's not. This is the real pipeline for releasing a version of React Native. Probably you're not able to read all the steps and don't worry, it's fine. This is just to showcase how much work goes into one or any given React Native release that we do currently. In particular, this is what we've used for 62. And also I had to squash together some steps in order to make it readable. One thing in particular, that I want to point out, is that the step I was showing you earlier is actually over there.

It's one of them, but it's really, really far ahead and there's a lot else going on. And I'm pretty sure that right now what you're asking yourself is why is that complicated? What's the complexity? And I can sort of like tackle two different series of complexities. The first kind is actually related to a series of things that happen in any sort of like medium to big open source project. Like these are generic complexities that most of us doing open source may face. For example, the fact that you care about the community. It may sound weird, but basically whenever you care about your community, whenever you do a release, you want also to produce the material so that your developers, the developers using your library, can actually consume it well. So in React Native, in particular, where we feel strongly about it, we have the changelog blogpost, we do diffs so that UpgradeHelper can show what you need to do, we have the documentation and a lot of other things. And also we do a lot of manual testing because yes, we trust CI, but also we don't. Also, the codebase moves really, really fast. In particular, in React Native, we have around 400 commits landing every month, which makes, you know, it's a challenge to keep up with that pace. And in particular, talking about code moving fast, since React Native depends on React, for example, depends on the Android and iOS ecosystems, we also need to keep moving fast enough so that we can catch up to all these other libraries. It may sound trivial, like, oh, well, React, you just need to bump the version library, right? Well, not really. For React Native to use a specific version of React, it needs to have a sync commit where some manual work is involved. And I left there an example. But talking about React Native-specific complexities, I've sort of, like, tackled two in this slide. One, which is probably the one there's most misconception around, is that Facebook is the owner of React Native, but the community manages the releases. And this is something that, and I'll talk a bit more about it later, like, it's been improving, but Facebook internally, in their monorepo, they use React Native. Like, they don't do React Native in it, so their experience of the code is different. Also, because the code of React Native is not open source first, as it happens for React, but it's a mirror of the code they have in their monorepo, when a person from the React Native team does a commit internally, then that gets replicated into the master branch of the open source version without going through the standard PR procedure. It doesn't go through the same CI. So sometimes, because the CI internal and the CI external are different, sometimes the CI external may break. And also, Facebook can always have the last word or the last say. Or they can decide something about release, and we have to keep up with these new requirements. Also, because as I mentioned, the codebase moves fast, and the release process goes through branches, so per each stable release, we do a branch. Sometimes it's hard to do patch releases. So if, let's say, 62.1, we wanted to cherrypick a commit, but this commit landed, let's say, two months after the point in which we cut the branch, cherrypicking it, which is a procedure in Git to take a commit and reapply it into a branch, may lead to conflicts. So that introduces a bit of complexity. So, as I mentioned, while there are these complexities, in particular the Facebook aspect, it's improving, like it's improving a lot, and I'm going to mention a bit more about it in a bit. But now, let's review those steps. As I was saying, a lot of work, a lot of iterations, a lot of steps that we do here are not strictly because of the code, but because we care.

As you can see, all the yellow, it's all things that we do for generating community-related material, so the documentation, the blog post, the diffs for the upgrade helper, and also there's a lot of manual testing that we do to ensure that we can trust the AI, but also that we are reliably seeing the code behaving. You see, all of this is because – and this kind of started even before this comment, but this comment really highlighted the problem around direct-need-to releases and has really left the whole set of people working on this issue with the constant question in the back of our mind of, how do we solve this problem? And I think that the easier answer to this is that we solve what we can and we work around what we can't. You know, as I just mentioned, it's really complicated, so it's not like we can actually tackle every single problem. For example, when it comes to solving, one thing that we have done, which has been quite useful, is the introduction of the RC phase, as we call it. And some of you may be like, oh yeah, we've been doing that forever. No, actually the first time we did it was version 60, which even I was confused. I was like, oh, no, we should have done that even way before that. But also the reason why we started doing that is because each release is tested before getting to point zero and make sure that the cause is stable and all the major regressions are cut before that. Also, we've introduced more people to the process, like when I started doing this, it was basically just Mike, then I joined him, and usually it was either me or him, and then we got either Ciarpini or Hector Ramos to help us for the website and the documentation part, but now, and it's so refreshing and it's so nice to see, we have at least four to five people constantly involved in every release, and there are even more that are more like drive-by, they do one thing, they help, and then they sort of like go back to do what they were mostly focused on. And also, as I mentioned already before, there's a really good increase in communication with Facebook lately. It's not just a general thing, it's also thanks to Eloy from the Microsoft team, as I already just mentioned, and every other member from the Facebook team really stepped up. Eli in particular has been a big proponent of this new level of communication as like this issue highlights, he opened this issue about 63, which is a version that has not even been cut in terms of branching. And it's incredible because he took the time to already tell us like what's going to happen in that version, what work is required and some dates around it, which is incredible. To me, seeing this new level of involvement, it's really heartwarming and I can see this increasing more and more over time.

Talking about work arounding though, for example, we are quite sure that it's never going to get to the point of an upgrade being a one line script. There are a couple in the CLI over time over the past few years they have tried to go for that route but in our experience, they never actually fully support or like leave your code base clean after being run. And that's why we've created Upgrade Helper which is a web app and I really hope that you all know what it is by this point it's been around for a couple of versions and the new Upgrade Support repo. And they are both ways for the community to come together and to help each other out in upgrading from a version to another. And also we are aware that we cannot fully automate the complete process of releasing which is why we incrementally iterate on this process on the bullet point list like it's never been that list from start. That's a progress, that's a work that we started back then and it's still improving right now. Like, for example, Eloy is doing right now another PR to improve the script that we use for end-to-end testing manually when we do the branching and the testing locally. And also Lucas has been doing a big work for the upgrade helper. They are planning now to basically make the whole part of generating new DEVS completely automatic. So, again, it's a constant process of improvement over what we cannot solve completely.

So, to sum it up, releasing React Native - I hope at this point I've convinced you - is really complicated. The code base moves really, really fast and everyone involved is working to improve it, to improve the experience. Not just releasing it, but also the actual release and the experience for everyone consuming React Native so that everyone can have a better experience with it.

And, again, it's not just people from the community. It's the Facebook team and the Microsoft teams that have been collaborating a lot and collaborating way more than just me personally.

That said, let's go back to the title of my talk, in a way. I'm pretty sure by this point you're like, yeah, sure, OK, it's complicated, but wouldn't 1.0 be the final solution? Wouldn't having a version 1.0 fix all my problems? Like, should I wait for 1.0 to use React Native in production? And to that, my answer is a clear no. Let me explain. 1.0, per se, is just semantics. 1.0 is a promise. It's a promise of having a finalized product, so like, OK, that square, now it's complete, and it's a square that I can promise is going to work the way it should, it's the way I envisioned it, and also it's kind of bringing with it a promise of long-term support. Like, we're not used too much to have you know, many major releases, one after the other, in particular, for bigger pieces of software without, like, massive breaking changes and usually, we would expect you know, the major, to be supported for a long time. But that said, 1.0 doesn't mean that the product is not not usable, like simply because 1.0 is not there doesn't mean React Native cannot be used. Like, take Gmail. Like, let's go in a completely other realm. Let's talk about a piece of software that has been around for a really long time. Probably most of you don't remember this. But like, when it was released for the public, it actually was still in beta. Like, you have the Gmail logo with the beta label and it stayed in that way for 5 years. And why is that? Well, because that label was there to say hey folks, we're still working on it. We're still tweaking it and adding new things. Which is sort of what's happening with ReacNative. So, are we doomed? Like, since we don't get 1.0, should we never use ReacNative in production? I hope that by this point you kind of already know where I'm going with my answer. But the answer, of course, is heck no. Like, ReacNative is already vastly usable. Like, it's been successfully used all around the world. So many companies have used it successfully. Of course, not everyone, but hundreds and hundreds have. I've been a ReacNative developer for three to four years right now. And all the projects I've worked on are still there, are still around, still kicking, and I'm still really sure that it's been the right bet for those projects.

Also, as you may be aware, there's a long-term plan actually in place now, which is the new architecture of React Native. And in particular, I'm gonna say this, let's keep it secret between us basically, but we're talking already with Facebook to about how we should handle releasing one of the first pieces of the new architecture in the future, and we're trying to create a roadmap for that. So there's a long-term plan, we're already acting on it and we're trying to make it sure that it's the least breaking experience possible for everyone.

So, you can rest assured that we're constantly trying to improve. So as I was mentioning, to close it off altogether, the release process is complicated but for good reasons. React Native is still moving and everyone knows it still and 1.0 1.0.0 is still far away for React Native. So yeah, basically, 1.0 is a lie and you can just have fun using React Native right now.

I want to thank you all for sticking around, listening to this conversation, I hope that you enjoyed learning a bit more about the releases. My contacts are over there, you can reach out to me at my twitter, I have an email address over there and if you're watching this live, now we are going to have a Q&A and then there's going to be a speaker room and then there's an advance launch, so if you have any extra questions, please, please, please, ask me over there and I'm going to post the slides on my twitter quite soon. Thank you for staying around.