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 Calcet. I'm a software engineer at Formidable for the UK office in London, where I live. I'm a react Native core maintainer, which is maybe why you may know about me. And I'm 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, you know, we start with the right foot. So to give you a bit of context, I've been a developer in react Native for 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 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 on your comments while doing the presentation. But please let me know which version you've been using, like since how long have you been around for react Native? Like, 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. It's not just that. Like technically when you expose your code on GitHub, for example, the package.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. Like it's that. And also like this is one of the reasons why like the dynamic dependencies, the use of the carray for some dependencies. I don't really like that. I prefer like strict staticness. And why I like that? Because it allows reproducibility. So 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. So like, 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 as 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. Calcite.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. The way I release this is usually I just do a commit. 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, from 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, it's all done, we have an app ready to be bundled, ready to be sent to the source 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. Like, 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 like 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? Like, 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 blog post. We do divs so that Upgrade Helper 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, like, yes, we trust CI, but also we don't. So we do manual testing a lot. Also, the code base 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. Like, it may sound trivial, like, oh, well, Rect, 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. They do it differently. 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, you know, decide something about release, and we have to keep up with these new requirements. Also, because, as I mentioned, the code base moves fast, and the release process goes through branches, so we do per-reach stable release, we do a branch. Sometimes it's hard to do patch releases. So, if, let's say, 62.1, we wanted to cherry pick a commit, but this commit landed, let's say, two months after the point in which we cut the branch, cherry picking 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, like, 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, you know, we can trust CI, 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 native 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 other 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, like, the reason why we started doing that is so that we could increase the ways that each release is tested before getting to point zero, and make sure that the code 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 Charpeny or Hector Ramos to help us for the website and the documentation part. And it's so refreshing and 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, like 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. Like 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, like 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 that have tried to go for that route, but in our experience, they never actually fully support or like leave your codebase 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 the 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 some great work for the Upgrade Helper. They are planning now to basically make the whole part of generating new divs 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 actively 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 into this open source aspect of it, which makes things really, really reassuring. But that said, let's go back to the title of my talk in a way. I'm pretty sure that by this point you're like, yeah, sure, okay, 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. So you see, 1.0 per se is just semantics. 1.0 is a promise. It's a promise of having a finalized product. So like, okay, 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 many major releases, one after the other, in particular for bigger pieces of software without massive breaking changes. And usually we would expect the major to be supported for a long time. But that said, 1.0 doesn't mean that the product is 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 had the Gmail logo with the beta label, and it stayed in that way for five 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 react Native. So are we doomed? Like, since we don't get 1.0, should we never use react Native 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, react Native 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. And I've been a react Native 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 going to say this. Let's keep it a secret between us, basically. We're talking already with Facebook about how we should handle releasing one of the first pieces of the new architecture in the future. And we are trying to create a roadmap for it. So there's a long-term plan. We're already acting on it, and we're trying to make sure that it's the least breaking experience possible for everyone. So, you know, 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 is still constantly improving. No one is standing 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 account. My DMs are open. 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 advanced lounge. 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.