00:00 So the conventional comment approach has some very well-defined mappings of how a type gets translated to an actual version increase. So for instance, a fixed type gets to a patch release, a feature to a minor release, and a breakage change to a major release. But what about things like docs? What about things like chore?

00:18 Or what about things like, for instance, custom-defined types? Because maybe in our design system, we want to have something like style as a type defined, so we can kind of make sure or define how that affects the actual version increase. Now let's have a look how we can customize that in NxRelease in combination with conventional comments.

00:38 So if you go into the @nx/jsON, that's where we usually define or fine-tune how NxRelease behaves and adjusting its defaults. Now we have already here conventional comments enabled. And what we can do now here is have another section that's called conventional comments. And in here, we can define here different types.

00:58 Now you can see already, CurseRouter completes that for me. So as a first step, what we can do is say for the docs type, for instance, we want to enable that because by default, that's disabled. Now let's start actually with a disabled case so we can see how this changes as we fine-tune these values.

01:15 Now in order to be able to actually simulate that, let's create some comments. We have here a release 1.1.0 in our git history. So let me just go to the forms library here and say here, add some cool docs. That is like a new docs release that we added. Just comment that.

01:33 Now let's also go, for instance, into the buttons library and have a bug fix. All right. So with that, we now have some commits on top of our last release. Now that allows us to go and run the versioning and see what happens in terms of the changelog.

01:53 Now if I run again nx-release and dry run mode, now let me scroll up a bit and just basically look at the changelog here, which will allow us to see what version changes, but also like how it is being reflected in the changelog itself. And so you can see we get a patch release because we have this fixes commit on the buttons

02:10 where we added some bug fixes, but you can see there is no mention of the docs changes at all. Now if I go in here in the settings and change this to true and I run again, if I scroll up, now you can see the version is still the same, but we get now also a documentation

02:27 entry in here, which says on the forms package, we added some docs. This is being highlighted in here, which can be important for your package. Now we could go even further and define our custom types. So for instance, here we would have a style type, and we can then add a new object in here and define a semver bump for this one.

02:46 We could have done the same for docs, but for docs it doesn't really make a lot of sense. But for style, for instance, we might want to have that appear in our logs, in our changelog, but we might also want to have that in effect of the actual increase of the version. And so whenever we have, for instance, a comment that says style and then forms, and then some

03:06 description of that change that we make, maybe this is interpreted in our specific change as a feature increase, and so it might bump the minor version. And so we can control that by actually saying here this bumps the minor version. And so now let me actually go and add a new style entry.

03:22 Let's go to the themes and just like add here, default, now have an entry that has a style and is in themes. Now if we go again and run the release process.

03:40 So let me scroll up a bit again to the changelog entry. And now you can see we actually get the one, the two, the zero. And the reason is because as we just changed here, the style in December bump should result in a minor bump. And so therefore we get one, the two, the zero. We still get the fixes, obviously documentation changes in here.

03:57 And now we also get a styles entry with even a nice icon in front of it. And the message obviously that comes from the comment message that we created. And so this allows you to actually really fine tune and adjust the different types when using conventional comments for your project and how that makes sense for your product specifically.