Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Branching strategy for 2.0 #1679

Merged
merged 2 commits into from
Sep 19, 2024
Merged

Branching strategy for 2.0 #1679

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6fc63df
Branching strategy for 2.0 development
mhatrevi Sep 17, 2024
6b313e1
Adding reasonable timeline
mhatrevi Sep 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions BRANCHING_STRATEGY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@

# Caliptra 2.0 Branching Strategy

A new branch, named **"main-2.x"**, will be created off of the main branch for Caliptra 2.0 development. This includes changes to ROM, FMC and Runtime.

- The **"main-2.x"** branch will not maintain backward compatibility with 1.x features.
- The **"main-2.x"** branch will adhere to the same rules, policies, and CI pipelines as the main branch.
- Any fixes made to the main (1.x) branch will be forward-ported to the **"main-2.x"** branch. These fixes will be cherry-picked from main to main-2.x to maintain a linear history. This will be a weekly exercise.

As the flow of 1.x fixes slows down or as we approach the point of making a 2.0 release (whichever occurs first), we will switch **"main-2.x"** to become the primary branch. We have two options to achieve this:

### Option X
Rename **"main-2.x"** to **"main"** and rename the older main branch to **"release-1.x"**. The **"release-1.x"** branch will become a long-term servicing branch for 1.x bug fixes, while the **"main"** branch will be the active branch for further 2.0 development.

### Option Y
Fork a branch from the main branch and name it **"release-1.x"**. This will become the long-term servicing branch for 1.x. Reverse integrate **"main-2.x"** into the main branch and deprecate the **"main-2.x"** branch. The main branch will then become the active branch for further 2.0 development.

We can decide between these options later, depending on their complexities.

This strategy strikes a balance between maintaining separate branches for development without backward compatibility and developing in a single branch with `#ifdefs` to support 1.x. It facilitates the 2.0 development, removes unnecessary 1.x compatibility overhead, and ensures ongoing support for the 1.x release.
Loading