Stable vs Development Branch

[sthaha]

In recent past we have had instances where bugs have crept into main branch
rendering the validation workflow in production unstable and unreliable. Ideally
we would like to see errors in validation go down over time.

The proposal is to make use of stable branch for releases while maintaining
main branch for ongoing development. This approach helps ensure that your
production code is always stable and reliable while allowing for continuous
development and integration without blocking PRs.

Below, I’ll elaborate on this concept, including its benefits, implementation steps, and best practices.

Overview of the Branching Strategy

Branch Roles

• main Branch: This is your primary development branch where all new
  features, bug fixes, and experimental changes are made.
  Developers work on this branch and push their changes regularly.

• stable Branch: This branch is used for releases and contains only code
  that has been thoroughly tested and is deemed stable for production.
  This branch should reflect the latest stable version/release of kepler
  application. This branch is where the bug fixes must land.

Benefits of This Approach

1. Separation of Concerns: By keeping development and production code
   separate, you minimize the risk of introducing bugs into your stable release.

2. Continuous Integration (CI): You can set up CI processes that automatically
   test changes in the main branch, ensuring that only code that passes all
   tests is merged into the stable branch.

3. Faster Feedback Loop: Developers can receive immediate feedback on their
   changes in the main branch, allowing for quicker iterations and improvements.

4. Controlled Releases: You can control when to merge changes into the
   stable branch, allowing for scheduled releases or hotfixes as needed.

Implementation Steps

1. Set Up Branches

• Create a stable branch with the HEAD pointing to 0.7.11 stable release
• Ensure that the stable branch is protected, meaning that direct pushes
  are restricted, and all changes must come through pull requests.

2. Configure CI/CD Pipeline

• Implement a CI job that automatically compares the main branch
  against the stable branch.
• This job should check for differences and determine if the changes
  in main are ready to be merged into stable.
• Modify Validation jobs to compare stable against main (development).

4. Merge Process

• Once the CI tests pass, create a pull request from main to stable.
• Review the changes in the pull request to ensure that everything is as expected.
• After approval, merge the pull request into the stable branch.

5. Releases

• Releases are always made from stable branch.