Speaker 1: Every single day, development teams are building and updating their code. And at some point, they need to take that code and push it out to the final product. We all know this is happening, but did you ever wonder how this happens? The way that this happens in a very practical sense is through what's called releases. And on this video, we're going to talk about how that happens specifically on GitHub, which is one of the most popular platforms. Let's take a look at a couple of examples. This first one here is dbt labs. It's the dbt code, which if you follow this channel, this is the tool that I am a huge fan of and that many companies are using. And if you look over here on the right, we see releases. We can see there's 87 releases that they've done. Here's another example. This is Airbyte. This is an open source data extract and transform tool. Over here, they have 83 releases. They're on an alpha version over here. Third, here's Apache Airflow. And theirs is actually a little bit different. If we were to open this, we can see the way they've done this. They're version 1.20. The first thing you may be wondering, or that we should touch on, is what do these numbers mean? And all of this isn't just made up. What it's based on is what's called semantic versioning. This is used to come up with your versioning number, that zero point or one point, whatever. And the way it works is like this, major.minor.patch. And what did those mean? An easy way to identify the impact that this release, this version is going to have on your code. If you're changing the major version, you're going from 0 to 1 or 1 to 2, you're making changes that are incompatible API changes. It's meaning what you've just released is not going to work on a previous version. Version 2 is not going to be completely compatible with version 1, and so on and so forth. Minor is when you're making a change that you're adding new functionality in a backwards compatible manner, meaning 0.2 should be compatible with 0.1. You're adding a new feature, but the foundation of it isn't completely breaking. It's not a completely different structure of the API or whatever you're working with. And then the last part, patch, is when you're making backwards compatible bug fixes. Instead of adding a functionality, you're fixing something that may have broke. The main idea here is to be able to iterate through your code, release versions, and do it in a way that everybody understands what's going on. The last thing I'll point out here is you may be something like a pre-release, and that's where you might see something like alpha. It's indicating to the public or whoever wants to use this that it's not completely production ready. You can use it, but just be a little weary of it. If we look back at Airbyte, they're on 0.30.16 alpha, so you can kind of get a sense for where this is in its development cycle. Along with the versioning number are tags, and if we look in the GitHub documentation, it says releases are based on git tags, which mark a specific point in your history, and they don't have to be the exact same thing as your release version. If you look up here, v1.508 is the tag. The release version is 1.580. You have that v in there. It's technically different, but it should match up, and that's how it's going to work. And if you want to learn more about git tagging, there's a whole bunch of documentation here, and I'll link this in the description. Before we go in and try to create our own release, I want to go back to what we're seeing here. What does this mean? Essentially, when you create a release, you're packaging up all of the code in your project at a given time and saying here are the files and everything that you need to know about this. In this case here, if we go to this version of dbt, they're adding some descriptions. You can add links to whatever you want, and if we go to the bottom, they do a great job of documenting this. Down here is assets, and here is the zipped up version of your source code. This is going to be everything about this code. If we open this up, we can see that exact version of the release that was shipped, and if you were to go to a previous one, you could see the assets here as well and do the exact same thing and see the code as it was at that release. Here's the tag as well. Here's the latest commit. You can compare between tags, so you can see the differences between one release or another. You can see it's incrementing here. That means there was likely a bug fix between these. You can also link to specific merge requests. This is a huge reason why version controlling in something like GitHub is so effective and so important because you can organize all of this stuff and link to it at a specific time, and everyone can see exactly what it is. Now we understand how this works. How can we create one? I have my own version of a DBT project. This is by no means a production-ready project. It's a mishmash of all sorts of things that I've been doing on this channel, but let's just see how would we create a release here. Right here, we can see I don't have any. Let's go ahead and create new release. First thing it's going to say is choose a tag, and we don't have one. We could either create a new tag on the fly or we can create a new tag on publish. I'll just create one right now. We'll call this v0.1.0. We'll start with zero because this is the first major version. You start at zero. One because this is the first edition, and zero because it's not a bug fix. This is the first one that we're going to create. I'll go ahead and create that tag. This tag will be created from the target. You could do it on a specific branch. I'll do master, and over here we can see some tagging suggestions as well, and here's a link to that semantic versioning. We'll call this my first release, and here we can do markup, whatever we want, just like we did before. Now if you have some attachments you want to add, you can add this here. We can drag and drop. We could say if this is a pre-release, meaning that it's not production ready. I'll click this just because it's not, and let's say publish release, and there it is. We're done. Here we can see it's marked as a pre-release. Here's the title, and here are the assets. So if we were to open this up just like before, we can see all of our code that we have in here. Anyone can see it, and here's the latest commit. Here's our tag. There you have it. That's how you create a release and get that going. One more thing I want to point out before we wrap this up is the ability to automate this process. You saw what we did. We manually went through some of those steps and created this release. If you've watched the video on GitHub Actions, you'll know that there are a lot of custom things you can do, one of which is creating a release. Now, I will point out here that this particular one that I'm landing on is archived by the owner, meaning it's not actively being managed, but this is just an example. It's an Actions, a GitHub Action to create a release, and you can see it allows you to put in information, name, release body. If it's a pre-release, all these things and create a workflow that will do this process for you. This is something you can do to automate your deployment process. If you know all of the steps you want to take, you can create a workflow, and at a push of a button, it'll create the release, and some of those manual steps are removed from that process. Again, this one in particular is no longer active, but there are several other ones that are maintained. So click into these and see the same kind of things that they're doing and incorporate them in your project. And we can see, hey, this one even has 288 releases. Wow, that'll do it for this video. If you have any questions on this, let me know. Thanks for watching, and we'll see you at the next one.