Contribute

Introduction

First of all, thank you! You have decided to contribute code to our software and become a member of the large shopware community. We appreciate your hard work and want to handle it with the most possible respect.

To ensure the quality of our code and our products we have created a small guideline we all should endorse to. It helps you and us to collaborate with our software. Following these guidelines will help us to integrate your changes in our daily workflow.

General information

We are using Conventional Commits

Conventional Commits is a standard way of formatting commit messages in software development. It helps teams communicate changes effectively, automate release notes, and improve collaboration. By using predefined types and scopes, such as feat for new features and fix for bug fixes, it simplifies the process of tracking and understanding code changes. That is why we are also adapt that to branch names.

Examples:

Branches

fix/resolve-issue-with-user-login-validation

feat/Implement-user-profile-image-upload-functionality

Commit message

fix: resolve issue with user login validation

fixes: #123

feat: Implement user profile image upload functionality`

fixes: #456`

Requirements for a successful pull request

To avoid that your pull request gets rejected, you should always check that you provided all necessary information. Here is a check-list with some requirements you should always consider when committing new changes.

• Do you made entries in the correct Upgrade.md file with a small documentation of your changes?
• Does your pull request address the correct shopware version? Breaks and features cannot be merged in a patch release.
• Is your implementation missing some important parts? For example translations, downward compatibility, compatibility to important plugins, etc.
• Did you provide the necessary tests for your implementation?
• Is there already an existing pull request tackling the same issue?
• Write your commit messages in English, have them short and descriptive and squash your commits meaningfully.

Branching model Shopware 5

In the Shopware 5 core project, there are main branches for each major version, such as 5.6 or 5.7. When creating a new development branch, it should be based on the latest version of the main branch. Typically, all work should be directed towards the main branch of the current major version, unless there is a planned release.

During a release, work on the main branch is paused to allow for the creation of a stable package that ideally remains unchanged. Simultaneously, a temporary branch called next is created or updated to the latest state of the current major branch. This next branch becomes the target for all new work during the release phase. It remains active from the preparation of the release until one or two weeks after the release date. This precautionary measure ensures that any critical issues discovered after the release can be quickly addressed with an additional release. After this transition period, the next branch is merged back into the main branch, and work continues as usual.

Workflow

• Before creating a pull request, it's important to ensure that your branch is up to date with the latest changes from the target branch. To accomplish this, we recommend performing a rebase on your branch: git pull --rebase repository-name target-branch (git pull --rebase origin 5.7)