Updating CONTRIBUTING.rst to capture the new git strategy adopted to…

… follow a monthly release cadence.

CHANGELOG.md

@@ -2,6 +2,14 @@
 
 This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+Please note the header `WIP-DEV` is to always remain indicating the changes done on the dev branch.
+Only when a release to the main branch is done, the contents of the WIP-DEV are put under a
+versioned header while the `WIP-DEV` is left empty
+
+## [WIP-DEV]
+- Updating CONTRIBUTING.rst to capture the new git strategy adopted to follow a monthly release
+  cadence.
+
 ## [0.18.0] - 2023-07-26
 - Add support to decode compressed instructions
 

CONTRIBUTING.rst

@@ -19,39 +19,52 @@ We develop with Github
 
 We use github to host code, to track issues and feature requests, as well as accept pull requests.
 
+Git Strategy
+------------
+
+The repo adopts a simple git strategy where all contributions to the repo are made to the ``dev``
+branch (i.e. all Pull-Requests must use ``dev`` as the target branch). On a monthly cadence (decided
+and controlled by the SIG-ARCH-TEST members) the ``dev`` branch will be merged to the ``main`` to by
+the official maintainers of the repo. This will create an official release capturing all the 
+development over the month into a single release.
+
+To implement the above strategy successfully the following needs be followed:
+
+* Developers: All pull-requests from developers must target the ``dev`` branch and the PR must
+contain an entry in the CHANGELOG.md file under `[WIP-DEV]` section.
+* Maintainers: When a making a release the maintainers shall assign semantic version number by
+updating the CHANGELOG and the respective python files before raising a PR from the `dev` to `main`.
+
 All changes happen through Pull Requests
 ----------------------------------------
 
 Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:
 
-1. Fork the repo and create your branch from `master`.
+1. Fork the repo and create your branch from `dev`.
 2. If you have updated the docs, ensure that they render correctly in the respective format.
-3. Make sure to create an entry in the CHANGELOG.md. Please refer to the section on versioning below
-   to choose an appropriate version number.
+3. Make sure to create an entry in the CHANGELOG.md under the `WIP-DEV` section. 
 4. Ensure the existing framework is not broken and still passes the basic checks.
 5. Please include a comment with the SPDX license identifier in all source files, for example:
    ```
    // SPDX-License-Identifier: BSD-3-Clause
    ```
-6. Bump the version of the tool to patch/minor/major as per the entry made in the CHANGELOG.md
-7. Issue that pull request!
+6. Issue that pull request - make sure the target is to the dev branch.
 
 Checks for a PR
 ---------------
 
 Make sure your PR meets all the following requirements:
 
-1. You have made an entry in the CHANGELOG.md.
-2. You have bumped the version of the tool using bumpversion utility described below.
+1. You have made an entry in the CHANGELOG.md undet the `WIP-DEV` section.
 3. The commit messages are verbose.
 4. You PR doesn't break existing framework.
 
-Versioning
-----------
+Versioning (for maintainers only)
+---------------------------------
 
-When issuing pull requests, an entry in the CHANGELOG.md is mandatory. The arch-test-repo adheres to
-the [`Semantic Versioning`](https://semver.org/spec/v2.0.0.html) scheme. Following guidelines must
-be followed while assigning a new version number :
+When issuing pull requests from the `dev` branch to the `main` branch, an entry in the CHANGELOG.md 
+is mandatory. The repo adheres to the [`Semantic Versioning`](https://semver.org/spec/v2.0.0.html) scheme. 
+Following guidelines must be followed while assigning a new version number :
 
 - Patch-updates: all doc updates (like typos, more clarification,etc) will be patches. Beautification enhancements will also be treated as patch updates. Certain bug fixes to existing code may be treated as patches as well.
 - Minor-updates: Updates to code with new extensions, features, run time optimizations can be
@@ -60,7 +73,13 @@ be followed while assigning a new version number :
   as major updates.
 
 Note: You can have either a patch or minor or major update.
-Note: In case of a conflict, the maintainers will decide the final version to be assigned.
+
+Each PR will also require the tools version to be bumped. This can be achieved using the following
+commands::
+
+  $ bumpversion --allow-dirty --no-tag --config-file setup.cfg patch  #options: major / minor / patch
+
+bumpversion can be installed using `pip install bumpversion`
 
 All contributions will be under the permissive open-source License
 ------------------------------------------------------------------
@@ -84,14 +103,3 @@ Write bug reports with detail, background, and sample code
 - What you expected would happen
 - What actually happens
 - Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
-
-
-Version Bumping made simple
----------------------------
-
-Each PR will require the tools version to be bumped. This can be achieved using the following
-commands::
-
-  $ bumpversion --allow-dirty --no-tag --config-file setup.cfg patch  #options: major / minor / patch
-
-