cpp_client_telemetry/docs/dev-branch-process.md

# Development Process

## Branches

Naming convention is simple and straightforward.

- **Main (main)** is the default branch available in the Git repository for the `current` release. Current SDK release is `v3.x`. This branch should be stable all the time and won’t allow any direct check-in. You can only merge it after code review. All team members are responsible for keeping the main stable and up-to-date.

- **Development (dev)** is the main development branch for the next major release `v4.x`. The dev branch’s idea is to make changes in it and restrict the developers from making any changes in the main branch directly. Changes in the dev branch undergo reviews. When ready, the branch will be fully promoted to `main`.

- **Master (master)** is the copy of `main` branch created after migration of original `master` branch to `main` branch. The branch is temporarily created to ensure that builds for projects using this repo in their CI pipeline doesn't start breaking immediately after migration. This newly created copy is locked against any new commits, and would be deleted in future once all the teams hae migrated their CI pipelines to build from `main`.

## Continuous Integration on `dev` branch

All of the existing tests are enabled on both `main` and `dev` branches. While implementing any refactoring changes, please adjust all tests accordingly.

## Documenting Feature and API changes

Please use Markdown format to document any API changes from v3.x to v4.x in [docs directory](../docs).

## Release labels for multiple versions

While the `main` branch contains linear history of all releases and associated git tags, it may be practical to branch-off specific releases for use in concrete products.

Sometimes a product may require a feature to be added on top of old long-term supported release.

Example branches to be created as-needed:

- `release/v3.6.123`
- `release/$product/v3.6.123`. For example, `release/edge/m102`.

All feature work made by committers (product owners) on old releases should be carried forward into the new release.
Committers use their best judgement how to plan the forward-porting of their change into latest release.

All feature work made by maintainers on latest release (or `dev` branch) will not be backported to old releases.
Commmitters use their best judgment if they'd like to backport a feature.

In case of a backport of a new feature to old release, `release/$product/v3.x.y` branch would be created.
Old release long-term support branches should never be full-promoted back into `dev` or `main`).

Continuous Integration is enabled on `release/*` branches.

## Compilers, Toolchains and Language Standard requirements for different releases

It may be necessary for the new release to require a new compiler or language standard. For example, starting with `dev` branch we would only support Visual Studio 2019 and above. `C++14` and above will also be required. It is possible that support for some build configurations will be dropped in the new release. It is also possible that some new features added to `dev` branch may not be backportable to old releases.