GitBook: [#2] Updated docs on packaging

SUMMARY.md

@@ -52,6 +52,10 @@
 
 * [Overview](sfpowerscripts/sfpowerscripts.md)
 * [Features](sfpowerscripts/features.md)
+* [Types of Packaging](sfpowerscripts/types-of-packaging/README.md)
+  * [Unlocked Packages](sfpowerscripts/types-of-packaging/unlocked-packages.md)
+  * [Source Packages](sfpowerscripts/types-of-packaging/source-packages.md)
+  * [Data Packages](sfpowerscripts/types-of-packaging/data-packages.md)
 * [Orchestrator](sfpowerscripts/orchestrator/README.md)
   * [Build & Quick Build](sfpowerscripts/orchestrator/build-and-quick-build.md)
   * [Publish](sfpowerscripts/orchestrator/publish.md)
@@ -70,10 +74,6 @@
 * [Modular Deployment](development-practices/modular-deployment.md)
 * [Organizing your code / config](development-practices/modularizing-your-code-config.md)
 * [Defining the boundaries of a package](development-practices/defining-the-boundaries-of-a-package.md)
-* [Types of Packaging](development-practices/types-of-packaging/README.md)
-  * [Unlocked Packages](development-practices/types-of-packaging/unlocked-packages.md)
-  * [Source Packages](development-practices/types-of-packaging/source-packages.md)
-  * [Data Packages](development-practices/types-of-packaging/data-packages.md)
 * [Dealing with Org Specific Metadata](development-practices/dealing-with-sensitive-metadata.md)
 * [Managing Profiles](development-practices/managing-profiles.md)
 * [Tracking Manual Steps](development-practices/tracking-manual-steps.md)

development-practices/modular-deployment.md

@@ -22,7 +22,7 @@ This model has the following issues on a large repository:
 
 #### 2. Deployment of Modules
 
-A module, be it second generation [unlocked package](types-of-packaging/unlocked-packages.md),[ org dependent unlocked package](types-of-packaging/unlocked-packages.md) or [source package](types-of-packaging/source-packages.md) is an alternate approach for selective deployment. A module is a collection of metadata types that are grouped together in terms of the functionality provided. For example, a logging framework as a module will consist of the apex classes, objects, or any other automation that pertains to logging. A module is deployed in its entirety and the lifecycle of a module is maintained as opposed to individual components.
+A module, be it second generation [unlocked package](../sfpowerscripts/types-of-packaging/unlocked-packages.md),[ org dependent unlocked package](../sfpowerscripts/types-of-packaging/unlocked-packages.md) or [source package](../sfpowerscripts/types-of-packaging/source-packages.md) is an alternate approach for selective deployment. A module is a collection of metadata types that are grouped together in terms of the functionality provided. For example, a logging framework as a module will consist of the apex classes, objects, or any other automation that pertains to logging. A module is deployed in its entirety and the lifecycle of a module is maintained as opposed to individual components.
 
 A modular deployment provides the following benefits:
 

sfpowerscripts/orchestrator/validate.md

@@ -29,15 +29,15 @@ The following are the list of steps that are orchestrated by the **validate** co
     **Standard Mode**\
     ****
 
-    * Deploy all the built packages as [source packages](../../development-practices/types-of-packaging/source-packages.md) / [data packages](../../development-practices/types-of-packaging/data-packages.md) (unlocked packages are installed as source package)
+    * Deploy all the built packages as [source packages](../types-of-packaging/source-packages.md) / [data packages](../types-of-packaging/data-packages.md) (unlocked packages are installed as source package)
     * Trigger Apex Tests if there are any apex test in the package
     * Validate test coverage of the package depending on the type of the package (source packages: each class needs to have 75% or more, unlocked packages: packages as whole need to have 75% or more)
 
     \
     **Fast Feedback Mode**\
     ****
 
-    * Deploy only changed metadata components for built packages as [source packages](../../development-practices/types-of-packaging/source-packages.md) / [data packages](../../development-practices/types-of-packaging/data-packages.md)
+    * Deploy only changed metadata components for built packages as [source packages](../types-of-packaging/source-packages.md) / [data packages](../types-of-packaging/data-packages.md)
     * Trigger selective Apex Tests based on impact analysis of the changes in the package
     * Skip coverage calculations
     * Skip deployment of package if the descriptor is changed

development-practices/types-of-packaging/source-packages.md → sfpowerscripts/types-of-packaging/source-packages.md

@@ -107,10 +107,3 @@ By utilizing a destructive manifest file, one could delete metadata components d
 
 **Short answer no**, source packages assume that dependent metadata is already there in your org before the metadata in the source package is being deployed. That being said, for purposes of development in scratch org, you could add '**unlocked package'** dependencies to a source package, so commands like prepare and validate (in sfpowerscritpts:orchestrator) will install the dependencies to the scratch org.
 
-## Why is the version number for source packages have to end with zero? Doesn't it support .next?
-
-At the moment, it is not supported. So ensure that all your source packages in your repository has '0' as placeholder for the build number which can be replaced by a build number passed as a flag by the build command Make sure to use the right variable name according to your CI/CD system, the sample below describes how to pass the build number using GITLAB CI/CD.
-
-```
-sfdx sfpowerscripts:orchestrator:quickbuild --buildnumber ${CI_JOB_ID} --configfilepath config/scratch-org-def.json --diffcheck --branch develop
-```