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.

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

How to choose the right branch #11208

Open
greg0ire opened this issue Feb 3, 2024 · 1 comment
Open

How to choose the right branch #11208

greg0ire opened this issue Feb 3, 2024 · 1 comment

Comments

@greg0ire
Copy link
Member

greg0ire commented Feb 3, 2024

Picking a branch

Now that 3.0.0 is finally released, the situation might be confusing for you as a contributor if you need to pick a branch.

Here is a flow chart you may follow, and there is equivalent text below if you prefer.

Below, we use the following aliases for the branches:

  • 2.20.x is "legacy patch"
  • 2.21.x is "legacy minor"
  • 3.3.x is "patch"
  • 3.4.x is "minor"
  • 4.0.x is "major"
flowchart TD
    A{Are you touching source code ?}
    A -->|Yes| B{Is this a bugfix / security fix ?}
    B -->|Yes| C{Does it apply to 2.x?}
    C -->|No| E[patch]
    C -->|Yes| D[legacy-patch]
    B -->|No| F{Is this a breaking change?}
    F -->|Yes| G[major]
    F -->|No| H{Is this a forward-compatibility improvement?}
    H -->|Yes| I[legacy-minor]
    H -->|No| J[minor]
    A -->|No| K{Are you touching markdown/rst files ?}
    K -->|Yes| C
    K -->|No| E
Loading

Fixes

Security fixes, and bugfixes should go to the lowest branch that they can affect (usually 2.18.x, 3.0.x for bugs that only affect ORM 3)

Deprecations

New deprecations can be added on 3.1.x. There should be a resolution of each deprecation in 4.0.x.
Improvement to the existing forward-compatbility layer such as deprecations that should have been added in 2.x can be added to 2.19.x.

New features and refactorings

Those should usually go to 3.1.x with the exception of features that simplify the upgrade path. These may go to 2.19.

Breaking changes

Breaking changes must go to 4.0.x. Each breaking change PR must come with a deprecation layer counterpart PR to 3.1.x

Mapping

Merges up

Once your changes land on a branch, they need to be merged up to other branches unless you are contributing to the major branch. That's done by maintainers, following this flowchart:

flowchart TD
    A(legacy patch) --> B(legacy minor)
    A --> C(patch)
    B --> D(minor)
    D --> E(major)
    C --> D
Loading
@greg0ire greg0ire pinned this issue Feb 3, 2024
@greg0ire greg0ire changed the title Branching strategy How to choose the right branch Feb 3, 2024
@mpdude
Copy link
Contributor

mpdude commented Feb 5, 2024

So, when we do merge-ups, we need to merge:

  • 2.18.x into 2.19.x
  • 2.18.x into 3.0.x
  • 2.19.x into 3.1.x
  • 3.0.x into 3.1.x
  • 3.1.x into 4.0.x

💎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants