00:00 In a real world project you don't want to increase versions manually and so usually you go for something like conventional commits that help you automatically determine the next version based on your commits. However sometimes that's too restrictive and so there's another way to actually achieve that which is by using so-called version plans or file-based versioning. And you

00:18 can configure that in NNX by enabling here version plans and set that to true and this will allow us now to create file-based versionings in our project. So let's commit this and now let me create a new branch. Let's say we develop a new feature and we're going to create a couple of changes. Let's say in the forms package here

00:38 we're going to actually add some improvements to our logging. So let me commit also this one here it says improve forms logging. Then let's go to our core package. Let's go here to our logic and also improve our logic. Really cool features here and let's commit this as well.

00:58 So now we have two commits added on top of our branch and we can actually create now a version plan that describes the changes. And so we can go and create this manually in the .NNX directory. We can just create a new version plans folder and create a new markdown file that describes the

01:14 change. However there is a much better and more straightforward way which is by just running nx-release-plan. Now what this is going to do it is going to compare our current branch to the main branch and check the commits and figure out which project got touched.

01:32 And in fact you can see it identified that these two projects got touched and so it's going to ask about what the changes are in which version and how it should be increased. Now just to lean a second on that you can actually customize that behavior because what is being used behind the scenes is like a head parameter which points to our branch that we currently have which is currently

01:52 my feet. And then there is a dash dash base parameter which points to the main branch. Now if for some reason you need to customize that you could provide these to the version plan command here. And so in this case we are using a single version approach and so let me

02:08 actually simulate this version plan creation by using the dry run approach so we can see the difference between the two approaches. And so here you can see it asks for which version we want to have our project being bumped. Notice also it asks all projects because we have all projects

02:23 in sync here. We didn't configure independent versioning and so here we can say this is a minor release and so let me just choose minor. What is the actual changelog message? Let me say like some core improvements. Again very descriptive. And so what happens at the end is it creates such a

02:41 version plan file in the .dnx version plans directory. Now here we use the dry run so it doesn't have that anything happens on the file system this is just to simulate. Notice also in that change file we just see default at the top here because it doesn't matter what project the change happened because all projects will be increased the same way. Let's take a quick tangent

03:00 on what would happen if we have independent versioning defined. So if we go to the configuration here say product relationship is independent and now we run the versioning again. So we again run release plan dash d for dry run. Now you can see it asks us for each individual package and so I

03:20 could say well for core this was actually just a patch that we made and then for slate forms this was actually a minor change so it should increase the second number. Now I can provide here the message for this change. We could also just leave this blank and if you leave it blank we would open

03:36 up an editor where I could say well for forms core logic of how logs are being printed out and for core some minor changes and I can exit this and now you can see again it will create

03:52 a version plan file but now would define actually for each project that for core was a patch release and for forms it was a minor release. Now for the sake of this experiment here let's go back to the

04:04 default single version approach and run our plan now with our dry run mode. So it again finds both projects it asks for all projects clearly this is just a minor release core improvements and would

04:20 now create the version plan file. So let's go up here and have a look at the file itself. This is a markdown file and the above top the top part here is what is called a front matter where you can define these properties and as you have seen before also quickly is you can actually be much more

04:36 verbose here in the description like explain the feature or for breaking changes actually provide examples of how to fix them such as this is being part of your documentation. Now this usually is part of our commit right this should be part of our PR. So let me add this one here and so we commit

04:53 this one here and this would now go up on github and be processed. Now this is a manual process because we need to create these version files on our own however we developers tend to forget things right so we want to make sure that each PR has such a version plan file attached and in order to

05:07 do so you can add the annex release plan colon check to your CI script which will then verify that such a version plan is actually present for each PR. Now once this goes through github it gets merged into main eventually right so let's simulate that by just merging our my feature

05:27 branch here so now we have everything in main and now someone is going to cut the release right so they would run annex release let's use the dash d for dry run so we can just simulate the run and again you can see we're not being asked what version should be released because this is being

05:43 determined by our version plans now however already in the changelog here we see that we get incremented to 1.2.0 because before we mentioned this should be a minor release and you also see the message that we defined in our version plan file.