00:00 so when it comes to applying versions in a monorepo to different packages you have different strategies that you can follow and it's basically fixed mode and independent mode so fixed mode means that all of the packages have the same version and if you have or change a

00:17 single package all of them are being incremented so let's have a look at our situation here let's say we want to add a new feature to forms forms is currently in 1.0.0 we would increment that to 1.1.0 but that would also mean we would increment all the other packages to 1.1.0 now intuitively

00:35 you might say that's actually quite a weird way of approaching things but it has actually a big advantage if you look at our system here our design system that we are working out here in this course the main reason why we have five different packages is because we want to give

00:50 our users the modularity of just installing what they need so they will install probably always the core package maybe the themes package and then let's say just the icons package if they just need icons or the forms package if they also need forms now having all of them in sync

01:06 version wise is a big advantage in terms of compatibility so which forms library version is compatible with which other icons library version now independent mode is actually different it's basically the opposite so each package can have its own version and you only increment the

01:22 version of the package that changes again having our same example if our forms library here changes and we add a new feature to it we would increase just that specific package here to 1.1.0 and all the other packages will remain the same that also means we would just go and

01:40 deploy and publish the forms package with 1.1.0 but all the others would not be deployed now the advantage there is that the user only downloads and installs the updates that have been made there's no need to install and download or re-download all the other packages but just the one

01:56 that actually changed it is easier to track from the user perspective which specifically changed rather than having to go and look up the changelog but clearly there is some more cautious caution to be applied on the developer side of things that publishes these packages to make sure the compatibility between these different versions is given or if it is not they need to increase

02:16 properly the versions to signal that to the end user so by default nx has fixed version mode so if we go right now into the nx json we don't have anything actually configured related to the nx release package there's just some auto configuration that nx itself uses and so we can add here a new

02:33 release property and we can set here project relationship and set that to independent now compared to the previous runs that we did if we now again run nx release and let me just use the write run here to simulate what is going to happen you will see we are not going to be asked as before

02:51 like this will be applied to five projects but rather we get the question per package so in this case you can see it asks what version do you want to apply to slate ui core well i just want to apply a patch version here what kind of change do you want to add to slate ui icons i want to apply

03:10 actually a minor change the slate buttons is a major change and the other one is a minor change the minor change and so now you can see all of these have been versioned independently so here for instance slate ui icons got 1.1.0 the slate ui buttons got 2.0.0 so obviously this was like

03:28 just arbitrarily assigning versions but this would be how you would go and apply this to your package json's and obviously this is being reflected properly also on the local package json dependencies so you can see here in the forms package it properly updated here the buttons icons and

03:45 core dependencies to their respective version that they got and so this is a way for you to actually apply versions independently to each package versus a fixed mode approach