00:00 So whenever we run NxRelease, we increment the version, we generate the changelog, but those changes are then actually committed to our git history with a very specific pattern. And so if you look at it here, for instance, on the version 1.2.0, we get this pattern here that is being added to our git history. So there's like a chore, and the scope here is released, and then it says

00:18 publish 1.2.0. And we also get a tag associated with it as well, which is 1.v1.2.0. So there's a v prefix there. Now, most of the time, this is perfectly fine, and this is what most people use, but sometimes you want to maybe customize it. And if you want to do that, you can actually do so by

00:37 always going to that @nx/jsON file. And in here, we can actually define the actual release tag pattern. And so in here, you can see that these tags should be the version prefix, and then we can interpolate it here with this special string, which is like curly braces version, which will

00:54 then fill in the actual version number. Now, we could go ahead, for instance, say something like we want to have it under releases slash v1, whatever the version is. And so this would now be our new tag pattern. And we can also go and change the actual git commit message. And so for that,

01:11 we can actually create this git node in here inside the release property of @nx/jsON, and then adjust the commit message. So here, for instance, I actually like the proposal. So we don't maybe want to have the release in here, but just have a global scope, and maybe say like we

01:29 just released, and then have here an actual version number and some emoji at the end. So let's test it out. Let me actually commit this. And now let's run a new release. Now when we run this, there's something going to happen. So have a look here. So it says here there's no git tag

01:49 matching this pattern that we just established. And the main reason is because right now, up until now, we always just used v and the actual version number, and not something like releases slash and the version tag number. And this is important because Nx leverages, at least by default,

02:04 the tag to determine which version was the previous one. And then from there on, it actually filters out all the commits, and then determines the next version that needs to be released, basically. So by default, you'd never run into this use case, because usually you establish this pattern initially. But for the sake of this example here, let me actually go and establish

02:22 and set up this pattern, so we can test it properly. Let me go to the v1.2.0 tag, and let me just tag here, or add a new tag based on here that matches our pattern, which would be something like this. Let's go back to main branch, and if I now show again, we can see now we have

02:42 this tag pattern now, and Nx should be able to find it. So let's run the release again. So now you see it runs through, it creates a new version 1.3.0, because we added this feature in here. It stages the files, commits them, tags them. We're not going to publish it right now,

02:59 so let's just skip this for now. And so let me now have a look at the history here. Now you can actually see that our changes got properly applied. So you see now we have these releases slash, and then the version number, and also our comment message changed. So we now have Tor, we just released v3.0, and an emoji at the end.