00:00 So when you follow a conventional commit strategy to generate your releases, by default here you also get a changelog at the very root of your project. And so here you can see the changelog of our version 1.1.0 release, which matches the features for the different projects here that we have in our workspace. Now there's only one changelog at the root

00:19 and not for each of the packages that we have. And this first one is because we use a single version here for all the packages. So all the packages are in sync. We could configure that to be an independent on the project relationship property, but we can also go here and define here a changelog property and say,

00:37 we want to have project changelogs and set that to true. And we also want to have workspace changelogs. So the workspace changelog is the one that we just saw at the very root of the project workspace here of our monorepo. And the project changelog will be per project. Now I have here already a bunch of commits

00:55 made on top of the 1.1.0 release. And so here you can see, we have here a fixed commit on the forms project, a feature on the core project and the feature on the themes project. So if I now run a release, it will increase the version to 1.2.0. We're not going to publish this now. And now we get a changelog at the very root

01:15 because we still have the workspace level changelog, which is 1.2.0, which includes all the features for core and themes and the fixes that we made and also the thank you parts at the very bottom here. And we also get changelogs for each of the projects that we have in our workspace. Now, interestingly, if you look for instance into the buttons one,

01:33 we just have a message there that says, this was a version bump to keep this buttons product in sync with all the other ones because we use that single fixed version for all of these packages. However, if we go into the forms, for instance, we'll see just the fixes or features that were added to the forms package. And similarly, if you go, for instance,

01:53 to the core package, where we also made a feature improvement, we'll just see the one of that specific package. So how does that filtering happen? Well, NX is able to figure out the changes, obviously, that we made in the commits. And so when it runs a new version release, it just reads all the different commits that have been made since the last release.

02:12 It analyzes the files that have been taught by these commits and maps them to the projects. And in that way, it is able then to filter these changelog messages per project.