GITBOOK-1022: No subject

SUMMARY.md

@@ -438,7 +438,7 @@
     * [Restart Deployment or StatefulSets to Redistribute Pods across Nodes](deployment/deployment-guide/redistribute-pods-across-nodes-by-restarting-deployment-statefulsets.md)
     * [Rerun Jobs in Kubernetes Cluster](deployment/deployment-guide/rerun-jobs-in-kubernetes-cluster.md)
 * [Development](development/README.md)
-  * [Module Packaging](development/module-packaging.md)
+  * [Packaging](development/packaging.md)
   * [Helm Charts](development/helm-charts.md)
   * [Versioning](development/versioning.md)
   * [Documentation Guides](development/documentation-guides/README.md)

development/helm-charts.md

@@ -70,7 +70,7 @@ If in [annotations](https://ranchermanager.docs.rancher.com/how-to-guides/new-us
 
 ## Helm chart versions
 
-The Helm chart version is mentioned under the `version` attribute in the `Chart.yaml` file (see [example](https://github.com/OpenG2P/openg2p-spar-deployment/blob/1.0.0/charts/spar/Chart.yaml)).  For version numbers, we adhere to [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html) with ["Simple 1-1 versioning"](https://codefresh.io/docs/docs/ci-cd-guides/helm-best-practices/#simple-1-1-versioning).  Here, the chart version is kept the same as the Docker version (also referred as `appVersion` in Chart.yml.).  
+The Helm chart version is mentioned under the `version` attribute in the `Chart.yaml` file (see [example](https://github.com/OpenG2P/openg2p-spar-deployment/blob/1.0.0/charts/spar/Chart.yaml)).  For version numbers, we adhere to [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html).  Any 3 digit version like `1.2.1` is deemed to be "frozen" version. 
 
 <table><thead><tr><th width="166">Chart State</th><th width="245">Chart version</th><th>Docker version (appVersion)</th></tr></thead><tbody><tr><td><strong>Release/Prerelease</strong></td><td>Matches Docker version</td><td>Matches Chart version</td></tr><tr><td><strong>Development</strong></td><td><code>0.0.0-develop</code></td><td><code>develop</code></td></tr></tbody></table>
 

development/versioning.md

@@ -6,7 +6,7 @@ description: Version and branch conventions followed in OpenG2P
 
 In general, OpenG2P follows  [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html). However,  there are exceptions concerning Oodo modules which follow [Odoo Versioning](https://setuptools-odoo.readthedocs.io/en/latest/#versioning).  
 
-Versioning is applied to the following artifacts.  
+## Versioning conventions for artifacts
 
 | Artifacts           | Versioning                                                                                                                                                                                                                                                                                                                                                   |
 | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
@@ -16,16 +16,19 @@ Versioning is applied to the following artifacts.  
 | Helm Charts         |  [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html). See more details [here](../deployment/helm-charts.md#helm-chart-versions).                                                                                                                                                                                                                  |
 | Repository branches | As per guidelines given [here](versioning.md#git-branch-and-tag).                                                                                                                                                                                                                                                                                            |
 
-## Pre-release versions
 
-Pre-release versions maybe appended with a tag like "rc1", "rc2" etc. For example "1.2.0-rc1".  Such a tag will be reflected in all the artifacts -- Odoo, Dockers, Helm Charts etc.
 
 ## Git branch and tag
 
-Typically, branches on Git repositories match the version number of the module/component.
+A moving branch may have names like `develop`, `17.0-develop` or even `1.2`.  Here `1.2` is considered a moving branch until a tag like `v1.2.2` is created.  
 
-For **Odoo** module repositories, a prefix of Odoo version is added to the branch name, e.g. `17.0-1.0.0, 17.0-develop.`Within a branch, multiple Git tags may be created like `17.0-1.0.0-rc1`, `17.0-1.0.0-rc2` etc.
+## Frozen versions
 
-For **non-Odoo** module repositories, you should find a `develop` branch in the repo where in-progress work may be checked-in.
+A version of any artifact (like a Helm chart, docker, git repository etc.)  is considered "frozen", or "tagged', or "pegged" if all the components, and source code inside that artifact is frozen -- there are no moving versions like "develop". Thus, a frozen version allows tracing to exact versions of code at the lower most level.  Conversely, a frozen version artifact can be exactly recreated if required.
+
+A 3 digit version is deemed [frozen](versioning.md#frozen-versions) if it does not have any other suffixes like -`develop` or `-alpha` etc. Conversely, any version which is not 3 digit or has a suffix, cannot be considered a frozen version. The version may have parts that are moving.  Here are some examples to illustrate the same:
+
+
+
+<table><thead><tr><th width="200">Artifact</th><th width="185">Version</th><th>Interpretation</th></tr></thead><tbody><tr><td>Git repository</td><td>v1.2.0</td><td>This is Git tag (not branch) and is frozen as tags are generally not moved</td></tr><tr><td>Git repository</td><td>1.2</td><td>A moving branch</td></tr><tr><td>Git repository</td><td>1.2.0</td><td>A branch created only to tag a version</td></tr><tr><td>Git repository</td><td>v.1.2.0</td><td>Tag (frozen) version</td></tr><tr><td>Odoo module</td><td>17.0.1.2.0-develop</td><td>Moving version related to branch 1.2.  </td></tr><tr><td>Odoo module</td><td>17.0.1.2.0</td><td>Frozen version </td></tr><tr><td>Docker</td><td>1.2.0</td><td>Frozen package</td></tr><tr><td>Docker</td><td>1.2</td><td>Moving version</td></tr><tr><td>Docker</td><td>1.2-develop</td><td>Moving version</td></tr><tr><td>Helm chart</td><td>0.0.0-develop</td><td>Moving version - latest in <code>develop</code> branch</td></tr><tr><td>Helm chart</td><td>1.2.3</td><td>Frozen package</td></tr></tbody></table>
 
-For releases, a release branch is forked out of the "develop" branch and given a version number for the release (like `1.2.0-rc1` or `1.3.0`). Subsequently, release specific check-ins like bug fixes are made on this branch. For the final release, this branch is Git tagged, frozen (no further check-ins allowed) and merged into the `develop` branch. Thus, all the changes related to the release are available in `develop` for further development. The recommended Github tagging convention for a final release is to have a prefix `v` before the version number. For example, `v15.0.1.0.0, release-15.0.1.0.0, v1.0.0, release-1.0.0`