Another option is to do it yourself. So at the moment, if I do a git log, we can see that commit there, and that's what we were binding to before. Add notifier to update thread notification. Let's create a new tag on our own. And as it turns out, there's two different ways you can create a tag. There's basically a lightweight option, and then a heavier option that creates a full object in the git database. Usually I opt for the latter. So to start, we will run git tag, and by default this will list all registered tags for your

Usually I opt for the latter. So to start, we will run git tag, and by default this will list all registered tags for your project. In this case, there are none. Let's add a new one. git tag -a for annotated. And this is going to be our 1.0 tag. Now if we don't provide a message with -m here, we can fill one out and exit out. Okay, so now if I run git log, you still don't see anything. But if we check out our tags, there we go.

Okay, so now if I run a git log, you still don't see anything. But if we check out our tags, there we go. We now have a 1.0 release. So this is just not a pointer to a commit, but it is a full object in the git database. So if you want to take a look at that further, we can take a look at the tag, and here we go. So you see we get quite a bit more information than if we used a lightweight tag, which is literally just a pointer to a commit. In this case, we can see I, myself, and the one who tagged it on this specific date, here's my message, and then here is what the tag is currently pointing to. But now, even if we try to push this up to GitHub, well, you can see everything's up

my message, and then here is what the tag is currently pointing to. But now, even if we try to push this up to GitHub, well, you can see everything's up to date. So let's just go back, and I'm sorry, back to releases, to tags, I still don't see anything. We need to specifically push the tags up. So you could say git push origin, so you're familiar with git push origin master, right? In this case, we want our tags. So we could say 1.0, or you can also add the tags flag, and that means push any tags that I happen to have for this project up to origin. In our case, we only have one.

Now, if we switch back, if you were to go to releases, creating that tag does create the release. They're connected. But in our case before, we wanted a nice description, and we don't have one here. Go back to tags, add release notes, and yeah, you're going to get the same thing here. So let's publish that. All right, and we're all set to go. Here's our latest release. So my point is, you can do this in either way. You can manually go to GitHub, create a new release, figure out, all right, here, figure

So my point is, you can do this in either way. You can manually go to GitHub, create a new release, figure out, all right, here, figure out which commit you want to bind it to, or within your code base on the command line, you can choose exactly when and where there should be a new tag. So great. But now, we do need to think a bit more, though, about our structure and how we perform new releases. Earlier, we touched upon SEMVR, which is semantic versioning, and that is basically a system, a standard for how you version your releases. So for example, when you make a change to the code base, will the next release be 1.0.1?