update design doc

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

docs/research/kcl-version-selection-design.md

@@ -1,6 +1,6 @@
-			           **KCL version selection strategy**
+<h4>KCL version selection strategy</h4>
 
-Author:  Akash Kumar
+**Author**:  Akash Kumar
 
 **Abstract**
 
@@ -22,35 +22,28 @@ Case 1:
 
 Currently if a package has two dependencies which point to two different versions of the same package (Refer to the below dependency graph for clarity) then both versions of the package get downloaded.
 
-![](/docs/research/dXO_Image_1.png)
+![](/docs/research/dep-graph.png)
 
 Case 2:
 
 Currently, if a package is already present in local then also it will redownload it.
 
 
-
+```bash
 $  ls -d /home/akash/.kcl/kpm/k8s*
-
 /home/akash/.kcl/kpm/k8s       /home/akash/.kcl/kpm/k8s_1.27
-
 /home/akash/.kcl/kpm/k8s_1.14  /home/akash/.kcl/kpm/k8s_1.28
-
 /home/akash/.kcl/kpm/k8s_1.17  /home/akash/.kcl/kpm/k8s_1.29
-
+```
+```bash
 $  kcl mod add k8s
-
 adding dependency 'k8s'
-
 the lastest version '1.29' will be added
-
 downloading 'kcl-lang/k8s:1.29' from 'ghcr.io/kcl-lang/k8s:1.29'
-
 downloading 'kcl-lang/k8s:1.28' from 'ghcr.io/kcl-lang/k8s:1.28'
-
 downloading 'kcl-lang/k8s:1.29' from 'ghcr.io/kcl-lang/k8s:1.29'
-
 add dependency 'k8s' successfully
+```
 
 Case 3:
 
@@ -66,33 +59,33 @@ Minimal Version Selection (MVS) operates on the assumption that each module spec
 
 version selection strategy is meant to provide algorithms for four operations on build list:
 
-- Construct the current build list:
-
-The rough build list for package M would be just the list of all modules reachable in the requirement graph starting at M and following arrows. This can be accomplished through a straightforward recursive traversal of the graph, ensuring to skip nodes that have already been visited. The rough built list can then be converted to the final build list.
+- **Construct the current build list:**
 
-- Upgrade all modules to their latest versions:
+	The rough build list for package M would be just the list of all modules reachable in the requirement graph starting at M and following arrows. This can be accomplished through a straightforward recursive traversal of the graph, ensuring to skip nodes that have already been visited. The rough built list can then be converted to the final build list.
 
-This can be achieved by running go get -u which will upgrade all the modules to their latest versions.
+- **Upgrade all modules to their latest versions:**
+
+	This can be achieved by running go get -u which will upgrade all the modules to their latest versions.
 
-Upgrading the modules would mean all arrows in the dependency graph is now pointing to the latest version of the modules. This will result in a upgraded dependency graph but changes in the dependency graph alone won't cause future builds to use the updated modules. To achieve this we need a change in our built list in a way that won't affect dependent packages built list, as upgrades should be limited to our package alone.
+	Upgrading the modules would mean all arrows in the dependency graph is now pointing to the latest version of the modules. This will result in a upgraded dependency graph but changes in the dependency graph alone won't cause future builds to use the updated modules. To achieve this we need a change in our built list in a way that won't affect dependent packages built list, as upgrades should be limited to our package alone.
 
-At first glance, it would seem intutive to include all the updated packages in our built list. But, not all packages are necessary and we want to include as few additional modules as possible. To produce a minimum requirement list, an helper algorithm R is introduced.
+	At first glance, it would seem intutive to include all the updated packages in our built list. But, not all packages are necessary and we want to include as few additional modules as possible. To produce a minimum requirement list, an helper algorithm R is introduced.
 
-**Algorithm R:**
+	**Algorithm R:**
 
-To compute a minimal requirement list inducing a given build list below the target, reverse postorder traversal is employed, ensuring modules are visited after all those pointing into them. Each module is added only if it's not implied by previously visited ones.
+	To compute a minimal requirement list inducing a given build list below the target, reverse postorder traversal is employed, ensuring modules are visited after all those pointing into them. Each module is added only if it's not implied by previously visited ones.
 
-- Upgrade one module to a specific newer version:
+- **Upgrade one module to a specific newer version:**
 
-Upgrading all modules to their latest versions can be risky, so developers often opt to upgrade only one module.
+	Upgrading all modules to their latest versions can be risky, so developers often opt to upgrade only one module.
 
-Upgrading one module mean that the arrow which earlier pointed to that module is now pointing to the upgraded version. We can construct a built list from the updated dependency graph, which can then be fed to Algorithm R to get a minimum requirement list.
+	Upgrading one module mean that the arrow which earlier pointed to that module is now pointing to the upgraded version. We can construct a built list from the updated dependency graph, which can then be fed to Algorithm R to get a minimum requirement list.
 
-- Downgrade one module to a specific older version.
+- **Downgrade one module to a specific older version.**
 
-The downgrade algorithm examines each of the target's requirements separately. If a requirement conflicts with the proposed downgrade, meaning its build list contains a version of a module that is no longer allowed, the algorithm iterates through older versions until finding one that aligns with the downgrade.
+	The downgrade algorithm examines each of the target's requirements separately. If a requirement conflicts with the proposed downgrade, meaning its build list contains a version of a module that is no longer allowed, the algorithm iterates through older versions until finding one that aligns with the downgrade.
 
-Downgrades make changes to the built list by removing requirements.
+	Downgrades make changes to the built list by removing requirements.
 
 **Implementation**