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

Jump to bottom

Supported branches improvements + hooks in patch versions #1872

Merged
merged 1 commit into from
Nov 26, 2024
Merged

Supported branches improvements + hooks in patch versions #1872

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
21 changes: 14 additions & 7 deletions contribute/contribution-guidelines/supported-branches.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@ weight: 30

# Supported branches

Maintainers will only accept contributions for branches which are subject to new releases.
Maintainers will only accept contributions for branches that are subject to new releases.

The **development branch** (`develop`) contains the development code for the next minor or major version, and is the natural destination for all contributions.

The **patch version branch** (e.g. `8.0.x`) contains the code for the next patch release for a given version. This is where some bug fixes are destined, under specific conditions.
The **patch version branch** (e.g. `9.0.x`) contains the code for the next patch release for a given version. Under specific conditions, this is where some bug fixes are destined.

{{% notice tip %}}
**TL;DR**
Expand All @@ -21,19 +21,26 @@ When in doubt, target the `develop` branch. We will ask you to rebase on the cor

The `develop` branch is always active and open to contributions.

Each minor version has its own patch branch: patches for the 8.0 version go in the `8.0.x` branch, while patches for 8.1 go in `8.1.x`... and so on.
Each minor version has its own patch branch: patches for the 9.0 version go in the `9.0.x` branch, while patches for 9.1 go in `9.1.x`... and so on.

These branches are created and closed following the support window of each version. Once the support for a version is over and no new patch releases are expected for it, its corresponding branch becomes closed to contribution.

Except for rare cases, a patch version branch is closed the moment the following minor version is released. For example, the `8.0.x` branch is closed once the 8.1 version has been released, giving way to the `8.1.x` branch.
Except for rare cases, a patch version branch is closed the moment the following minor version is released. For example, the `9.0.x` branch is closed once the 9.1 version has been released, giving way to the `9.1.x` branch.

**Pull Requests targeting closed branches will not be accepted.**

## Bug fixes and patch branches

Patch branches usually only accept critical bug fixes, like security bugs, and **same-version regression** fixes.
Patch branches accept all types of bug fixes, including critical issues, security bugs, and regressions introduced in the same version.

Regressions are bugs that break a feature that was previously working well. If a feature was working well in 8.0 and is broken by a bug introduced in 8.1, then the bug is a regression introduced in 8.1 and should be fixed in the `8.1.x` branch—as long as that branch is open.
A regression is a bug that breaks a feature that previously worked well. For example, if a feature worked in 9.0 but a bug in 9.1 caused it to stop working, that’s considered a regression introduced in 9.1, which should be fixed in the `9.1.x` branch—as long as that branch is still open.

If you intend to submit a fix for a regression introduced in a version that no longer receives patches, make sure that bug is still present in the `develop` branch. If the bug is still present, please submit a Pull Request on `develop`.
{{% notice tip %}}If you're unsure whether the bug is a regression, you can still submit your fix to the patch branch. Project maintainers will determine if the fix should be applied to the patch branch or redirected to the develop branch instead. {{% /notice %}}

If you want to submit a fix for a regression in a version that no longer receives patches, first verify if the bug is still present in the develop branch. If it is, submit your fix against the `develop` branch.

## New hooks in patch branches

While new hooks may be treated as features and therefore not accepted in patch branches, there are exceptions for hooks that are critical for the proper functioning of the module or aim to help with the situation where overrides are either required or not possible. Since overrides are not recommended, we may accept new hooks in patch branches to help developers avoid them.

In these cases, the maintainers may accept new hooks in patch branches. If you believe your hook falls into this category, [let's discuss it](https://github.com/PrestaShop/PrestaShop/discussions/categories/ideas) before submitting a pull request.
Loading