00:00 So if you work in a repo with multiple packages and potentially multiple contributors, having to define the next version every time can be kind of tough because you need to understand like what happened in the various packages. Maybe there were just some bug fixes, so it would just increment the patch version. Maybe there were some new features or maybe

00:17 there was even breaking changes. And so basically you want ideally to have some process that understands automatically since the last release what happened and therefore suggests the next version. Now there exists such a convention which is called conventional commits. Now if you want

00:33 to use such a semantic release versioning approach in NX with NxRelease, we can configure that. So again we go into @nx/jsON and add the release property in here if you don't have it already. And there you have the ability to say version and then here define conventional commits and

00:53 set that to true. And so this would now enable conventional commit versioning meaning the next time we run an NxRelease we would not be asked every time for what version we want to give a certain package but rather that would be deduced automatically based on our comments. So in order

01:09 to simulate that let's have a look here at our current log. Let's create a branch and add some conventional comments such that we can then run a new version. Right now we are at version 1.0.0 which you can see here by this comment message that had happened before as well as here the tag

01:24 that has been added and also in the package json of the corresponding packages. Let's go here into the forms package you can see we are at 1.0.0. So let me create here a quick branch and now let's make some changes. So first of all what we can do here is we made here the change of adding

01:42 conventional comments into the NxRelease process here and so we can commit that already. So let me just add that one and say git commit. Now this is a chore because we really just changed some configuration aspects of our repo. I don't have to give a scope so I'm just saying some chore

01:59 enable conventional comments. Next up we can go here into the forms library for instance and say we make some changes in here. So this could be just a bug fix and so again I'm going

02:12 to add that one. I'm going to comment fix and I can give the scope here of where this happens. I can use here the folder name or can use the actual package name for simplicity. Let me just say forms

02:24 adjust console message. Now let's go ahead and define some feature in the themes for instance or icons. Let's go into the icons add a new icon. So we have a new feature here where we add a star

02:40 icon. So again we commit that feature icons add the new star icon. Alright so if we now look at our logs our git log we can see we have a bunch of different messages now. We have first of all

02:55 a fix in forms we then have a feature in icons and so let's test a new release and see what happens. Again we just run NxRelease. I'm going with dry run again to see what happens. Now you can see already we didn't get asked any question of which type of increase we want to have which type of

03:15 version we want to assign but rather it has been inferred automatically and so let's have a look what happened. If we scroll up again here in the log you can see it reads here the slate core package which we didn't touch at all but it was resolved to be currently version 1.0.0 and resolved now to

03:32 specify as minor by using the git history and conventional comment standard and so the new version that it infers here is 1.1.0. Now notice that in this setup here in @nx/jsON we didn't specify any project relationship setup meaning that by default Nx uses a fixed project relationship

03:52 meaning all packages are version the same and always in sync. So even though we didn't change or touch the core package here it will be made it will be basically synchronized with all the other packages and increased accordingly and similarly for the other packages you can see

04:07 it increments all of them to 1.1.0. Now let's scroll a bit down and especially have a look at the changelog that got generated. I can see here we've got an update in the changelog we had 1.0.0 before down here then up here we see we have now version 1.1.0 with the date when it happened.

04:28 It says here the features that have been added in the icons package is to add a new star icon and there has been a fix in the forms package which adjusted the console message. So if we run this version now without a dry run we can see it will go and update or we skip the publishing for now as

04:46 well and now if you go in the changelog we can see how the changelog actually got rendered properly and updated you can clearly see where the feature has been added and where the fixes have been added and then let's pick up here for instance the forms package you can see the version got increased properly and also the dependent package got updated.