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.

Branches and commits

Branches and commit messages have the following prefixes:

Prefix	Name	Description
feat	Features	A new feature
fix	Bug Fixes	A bug fix
test	Tests	Adding missing tests or correcting existing tests
ci	Continuous Integrations	Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
chore	Chores	Other changes that don't modify src or test files
revert	Reverts	Reverts a previous commit

Branches

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

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

Commit message:

Use the following operators in the commit message body to close the issue:

• fix
• close
• resolve

fix: resolve issue with user login validation

fix: #123

feat: Implement user profile image upload functionality`

resolve: #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?

Branching model Shopware 5

In the Shopware 5 core project, there are main branches for each major version, such as 5.7 or 5.8. 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.

If the next major version (like 5.8) is already in development, but there are also still bug-fixes done on the current major (like 5.7), you need to merge up the changes to the next major branch. This could be done like this:

git checkout 5.8
git checkout -b merge-up
git merge --no-ff origin/5.7 -m "Merge branch 5.7 into 5.8" -n
git push

This will create a new branch from the next major branch. The changes from the current major branch are merged, after that the branch is pushed. Now a pull request has to be created. After this PR is merged, the changes from the current major are also in the next major branches. Before actually pushing, you may need to resolve conflicts.

The developing workflow on GitHub

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)

When you create a new pull request on GitHub normally it will get a first sight within a week. We do regular meetings to screen all new pull requests on GitHub. In this meeting there is a team of up to five shopware developers of different specialisations which will discuss your changes. Together we decide what will happen next to your pull request. We will set one of the following labels which indicate the status of the pull request. Here is a list of all possible states.

Label	What does it mean?
Incomplete	Your pull request is incomplete. It is either missing some of the necessary information, or your code implementation is not sufficient to fix the issue. Mostly there will be a comment by our developers which gives you further information of what is missing.
Missing Tests	When you want to commit a new feature or bigger change it is highly necessary that you provide the corresponding tests for it. We only accept new features or bug fixes which are completely tested.
Hacktoberfest-accepted	PR is accepted by us for Hacktoberfest.
Declined	Your pull request was declined by our developers and is closed. No reason to be sad. It can have very different reasons. We understand that it sometimes can be hard to understand the reason behind this. Mostly there will be a comment by our developers about why it was declined.
Closed by author	The author has successfully addressed the concern and closed the issue and the pull request accordingly.
Accepted	Your changes are finally accepted. The pull request passed our internal workflow. Your changes will be released with one of the next releases.

Important: The first two labels (Incomplete, Missing Tests) mean that you have to take action! After the label was added you have up to one week to update the pull request and provide the missing information or implementation. If there is no reaction from you within that week the pull request will be declined without further reason.

Why a pull request gets declined

So the worst thing happened, your pull request was declined. No reason to be upset. We know that it sometimes can be hard to understand why your pull request was rejected. We want be as transparent as possible, but sometimes it can also rely on internal decisions. Here is a list with common reasons why we reject a pull request.

• The pull request does not fulfill the requirements of the list above.
• You did not updated your pull request with the necessary info after a specific label was added.
• The change you made is already a part of a current change by shopware and is handled internally.
• The benefit of your change is not relevant for the whole product but only for your personal intent.
• The benefit of your change is too minor. Sometimes we do not have enough resources to handle every small change.
• Your change implements a feature which does not fit to our roadmap or our company values.

The Shopware CLA

When submitting your code to Shopware you need to sign our CLA (Contributor License Agreement). This CLA ensures that Shopware will stay an open and living product. In short, you give the explicit right to use your code in Shopware to shopware AG.